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Introduction 


Few can debate that Windows is the most popular desktop operating system 
on the planet. Still, when it comes to computer games, it’s a DOS world. 
Thanks to Windows’ sluggish graphics library, few games run well under 
Windows. And those games that do run tend toward less graphically oriented 
themes such as puzzles or card games. 


Microsoft is not unaware of Windows’ lack of appeal to game developers. 
They’re now bound and determined to fix up Windows so that it can perform 
as well as DOS. Microsoft’s current cure for Windows game woes is a small 
extension library called WinG. 


Using WinG, you can write programs under Windows that incorporate many 
of the programming techniques that make DOS games so successful. In fact, 
WinG works so well that even Doom, one of the most graphically demanding 
games currently available, has been ported to Windows. And, from what I’ve 
heard, it hums like a well-oiled machine. 


In this book, you'll learn the basics of incorporating WinG into your game 
programs. Along the way, you'll discover how to handle device-independent 
bitmaps, create identity palettes, modify bitmaps in memory, and much 
more. More importantly, you'll learn an amazingly simple technique for 
creating 3-D dungeon games such as TSR’s Eye of the Beholder series, and 
you'll do it all without page after page of complicated math! 


Who This Book Is For 


This book is not an introductory text for programmers interested in learning 
Visual C++ Windows game programming. To understand the programming 
advice that follows, you must have a working knowledge of C++ and be 
somewhat familiar with the Visual C++ development system. In addition, you 
should have some knowledge of object-oriented programming concepts. 
Previous Windows programming experience will also be helpful. In any case, 
you'll want to have a good Windows programming manual at your side as 
you work through the programs in this book. 
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Introduction 


Hardware and Software 
Requirements 


To compile and run the programs on this book’s disk, and to get the most out 
of the upcoming lessons, you must have at least the following: 


E An IBM-compatible 80386 with at least four megabytes of memory 
Windows 95 or Windows NT (Windows 3.1x users, see below) 

A hard drive 

A Microsoft-compatible mouse 


256-color VGA graphics 


Visual C++ 2.0 (Visual C++ 1.5x users, see below) 


As always, the faster your processor, the better. Fast processors mean fast 
compiles and zippy programs. This is especially true for Windows programs, 
because Windows pushes your hardware to the limits. Note that, although 
the programs in this book require Windows 95 or Windows NT, they can be 
easily modified for use with Windows 3.1x and Visual C++ 1.5x. Please refer 
to Appendix D for more information. 


Compiling the Programs in This Book 


The programs in this book were written with Visual C++ 2.0. This book as- 
sumes your copy of Visual C++ was installed using the default settings and 
directories. If you’ve changed any of the default settings or directories and are 
not sure how to fix errors that may result from these changes, you should 
reinstall Visual C++. 


The programs that follow are organized on this book’s CD-ROM by chapter. 
Each chapter’s programs are found in their own directory on the CD-ROM. 
That is, the programs for Chapter 2 are in the CHAPO2 directory, the pro- 
grams for Chapter 4 are in the CHAP04 directory, and so on. In addition, 
each program is contained in its own directory, based on the program’s 
name. So, the first version of the WinG example program is found in the 
CHAP04\WINGEX1 directory. 


To compile a program, copy its directory (and thus all its files) to your main 
Visual C++ directory. Then start Visual C++, open the program’s MAK file, 
and select the Project menu’s Build command. Note that the CD-ROM also 
includes an executable version of each program. You don’t have to compile 
the programs unless you really want to. 


How to Use This Book 


A Word to the Wise 


As every developer knows, a good program is virtually crash-proof. Error- 
checking must be done for every action that may fail, and appropriate error 
messages must be given to the user. Unfortunately, good error checking re- 
quires a lot of extra program code. For the programmer working on his next 
magnum opus, this is all just part of the game. But for an author writing a 
programming book, this extra code has different implications. 


A programming book should present its topics in as clear a manner as pos- 
sible. This means featuring programs whose source code is not obscured by a 
lot of details that don’t apply directly to the topic at hand. For this reason, 
the programs in this book do not always employ proper error checking. User 
input may sometimes go unverified, dynamic construction of objects is as- 
sumed to be successful, and (horror of horrors) pointers are not always 
checked for validity. 


In short, if you use any of the code in this book in your own programs, it’s up 
to you to add whatever error checking may have been left out. Never assume 
anything in your programs. Any place in your code that you can’t be 100 
percent sure of your program’s state, you must add error-checking to ensure 
that the program doesn’t come crashing down on your user. Just because this 
book’s author may have been lax in his error-checking (for good reasons), 
you are not off the hook. 


Also in the interest of clarity, little was done to optimize the code used in the 
following programs. You may see many places where the code can be rewrit- 
ten with faster algorithms. Unfortunately, the better an algorithm, the more 
it tends toward obscurity. In short, once you understand the principles pre- 
sented in this book’s programs, feel free to look for better ways to do things. 
With games, the faster the code runs, the better. 


How to Use This Book 


This book approaches its programs as hands-on programming projects that 
you can follow step-by-step. Rather than see an entire program all at once, 
you'll build each program version a piece at a time, inserting new code as you 
advance through the text. Each program version has its own section in the 
book, including a numbered list of steps you must follow to create that ver- 
sion of the program. There are three approaches you can take toward com- 
pleting each programming project: 
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Approach 1: Read each project’s steps and follow the instructions ex- 
actly, typing whatever new code is required. Although typing is a lot of 
work, it’s also the best way to learn, because you are forced to focus on 
each line of code. (Of course, typing code usually adds a bug or two toa 
program—bugs you'll have to search out on your own.) 


Approach 2: Read each project’s steps, but, instead of typing source code, 
use the Visual C++ editor’s cut and paste functions to add new code to 
the project. Copy the new lines from the source code on this book’s 
CD-ROM. This approach saves a lot of time and typing, but at the ex- 
pense of learning. You'll have to be more careful that you truly under- 
stand each step before you move on. 


Approach 3: Read each project’s steps, but don’t bother to build the 
programs on your own. Instead, run the executable versions of the 
programs supplied on this book’s CD-ROM. This is the easiest way to 
get through the book, but also the least educational. If you’re an expert 
programmer and are already knowledgeable about Visual C++, then you 
can probably get away with the easy way out. 


Notice that all three approaches to using this book start with Read each 
project’s steps. This is important, even if you’re not actually building the ex- 
ample programs yourself. Smaller pieces of source code are explained within 
the steps themselves, whereas larger functions are explained in their own 
section of the text. In short, you must read all the steps, as well as the regular 
text, to get a full explanation of each program. 


Someone Hand Me a Torch 


You're probably anxious now to dive into Dungeons of Discovery. Not only 
are you going to learn new techniques for writing successful Windows games, 
but you're also going to take a trip through the dark, winding hallways of an 
ancient Aztec dungeon. At the end of your journey, you'll emerge a better 
game programmer—that is, if the monsters don’t eat you first. 


Clayton Walnum 
January 1995 


Chapter 1 
An Introduction to 
Game Programming 


In my wild-and-woolly youth, I was a guitarist in a semiprofessional rock 
group. I'll never forget the first time I walked into a recording studio to record 
a demo song with my band. In the control room was a huge mixing board 
with more buttons and switches than there are teeth in a Great White shark. 
To the right was a patch bay from which snaked dozens of patch cords, each 
connecting some vital piece of equipment to another. Lights blinked. Reels 
spun. Sound processing equipment with fancy names like “phase shifter,” 
“digital delay,” and “multiband equalizer” clicked on and off. 


When I looked at all that complex machinery and considered that I was pay- 
ing $60 an hour (the equivalent of about $150 an hour today) for the privi- 
lege of being there, I almost turned around and walked out the door. It 
seemed to me that just learning my way around this complicated studio 
would cost me my life savings. I could see myself being ejected penniless from 
the premises without having recorded even a note. 


Luckily, I’d had some studio training, so I at least knew in a general way how 
a studio worked. In addition, like everything else in life (well, almost every- 
thing), a recording studio is not really as complicated as it looks. 


The same thing can be said about computer games. When you sit down at 
your computer and play the latest arcade hit or plunge into the newest state- 
of-the-art adventure game, you may be in awe of the talent and work that 
went into the glowing pixels that you see before your eyes. (And you should 
be.) But, just like recording a song in a studio, writing games for Windows is 
not as difficult as you may think, especially when you use the WinG library 
to speed things up. 
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If you’ve had some programming experience, you already have much of the 
knowledge and skills that you need to program a computer game. You need 
only refine those skills with an eye toward games—Windows games in par- 
ticular. In this chapter, you get a quick look at some of the skills required to 
develop and write computer games. 


Why Program Games? 


You probably bought this book because you wanted to have a little fun with 
your computer. There you were in the bookstore, digging through all those 
very serious programming manuals, when this volume leaped out at you 
from the stack. “Hey, this looks way cool!” you thought. But when you were 
walking to the cash register with this book in hand, you might have felt a 
little guilty. After all, games aren’t serious computing, are they? You should 
be learning to write spreadsheet programs, databases, and word processors, 
right? 


Let me tell you a quick story. 


Way back in the dark ages of home computing (1981, to be exact), I got my 
first computer. It was an Atari 400, and like everything Atari at that time, this 
powerful little computer was best known for its game-playing capabilities. 
The early 1980s were, after all, the beginning of the golden age of video 
games, and Atari was the reigning king. 


Unfortunately, after a few phenomenally successful years, video games (and 
computer games) spiraled into rapid decline, taking many companies in the 
industry down with them. Computers became serious again. Although Atari 
managed to survive (barely), it would never be regarded as the designer and 
manufacturer of serious computers, thanks to its status as a game-computer 
maker. This is a shame, because the Atari ST computer (the Atari 400/800’s 
successor) was—along with the Macintosh and the Amiga—way ahead of its 
time. Certainly these products were light years more advanced than the “seri- 
ous” IBM clones that gained popularity at that time. 


The problem was that darn gaming image with which Atari had been saddled. 
Who wanted to use a game computer to manage a spreadsheet, balance a 
bank account, or track an investment portfolio? That would be kind of dumb, 
wouldn’t it? 


Not really. The irony is that a computer capable of playing sophisticated 
games is a computer that’s capable of just about anything. A good computer 
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game taxes your computer to the maximum, including its capability to pro- 
cess data quickly, to generate graphics and animation, and to create realistic 
sound effects. Only a state-of-the-art computer can keep up with today’s 
high-powered games, such as Microsoft’s Flight Simulator 5.0. In fact, there 
are few business applications in existence that require more computing power 
than a sophisticated computer game. If you’ve used Windows for a while, the 
proof is right before your eyes. Under Windows, you can use the most sophis- 
ticated applications programs on the planet. But where are all the great 
Windows games? Most games are written to run under DOS, because 
Windows is just not zippy enough to handle them. 


Similarly, a programmer who can write commercial-quality computer games 
can write just about any other type of software as well, especially considering 
today’s focus on graphics and sound in applications. You may have pur- 
chased this book to have a little fun with your computer, but before you’re 
done, you will learn valuable lessons in software design and programming— 
lessons that you can apply to many different kinds of software. 


So, why program Windows computer games? Mostly because it’s fun! But 
remember that your game-programming experience will help you with every 
other program that you ever write. Gee, learning and fun. What a great 
combination! 


The Elements of Game Programming 


As you've already discovered, good computer games push your computer to 
its limits. In fact, a good computer game must excel in many areas. To write 
computer games that people will want to play, then, you must gain some 
expertise in the related areas of programming. These areas represent the ele- 
ments of game programming: 


E Game design 

@ Graphic design 

Sound generation 
Controls and interfaces 
Image handling 


Animation 


Algorithms 
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E Artificial intelligence 


E Game testing 


These game-programming elements overlap to an extent. For example, to 
learn graphic design for computer games, you need to know how a computer 
handles graphic images. Moreover, game design draws on all the other ele- 
ments in the list. After all, you can’t design a game unless you know how the 
graphics, sound, controls, and computer algorithms fit together to form the 
final product. 


In the rest of this chapter, you learn more about each of these game 
elements. 


Game Design 

Whether your game is a standard shoot-’em-up, in which the player’s only 
goal is to blast everything on the screen, or a sophisticated war game, requir- 
ing sharp wits and clever moves, first and foremost your game must be fun. If 
a game isn’t fun, it doesn’t matter how great the graphics are, how realistic 
the sound effects are, or how well you designed the computer player’s algo- 
rithms. A boring game will almost certainly get filed away in a closet to 
gather dust. (Ever seen a floppy disk being used as a coaster? Chances are the 
disk contained a bad computer game!) 


Many things determine whether a game is fun. The most important thing, of 
course, is the game’s concept. Often, a game concept is based on some real- 
world event or circumstance. For example, chess—probably one of the most 
popular board games of all time—is really a war game. Monopoly, on the 
other hand, is a financial simulation in which players try to bankrupt their 
competition. 


Computer games are no different from their real-world cousins. They, too, 
must have some logical goal for the player and—with rare exceptions—be set 
in some sort of believable “world.” This world can be as simple as an on- 
screen maze or as complex as an entire planet with continents, countries, and 
cities. In the insanely addictive computer game Tetris, the player’s world is 
simply a narrow on-screen channel in which the player must stack variously 
shaped objects. On the other hand, in the fabulous Ultima series of graphic 
adventures, the player’s world is filled with forests, swamps, cities, monsters, 
and the other elements that make up a complete fantasy scenario. 


Whatever type of computer world you envision for your game, it’s imperative 
that the world have consistent rules that the player can master. For a game to 
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be fun, the player must be able to figure out how to surmount the various 
obstacles that you place in his path. When a player loses a computer game, it 
should be only because he has not yet mastered the subtleties of the rules, 
not because some random bolt out of the blue blasted him into digital bits 
and pieces. 


Of course, to build a logical, fair, and effective gaming world, you must draw 
on all your skills as a programmer. All the other areas of programming in the 
previous list come into play here. Graphics, sound, interface design, com- 
puter algorithms, and more all help determine whether a game is ultimately 
fun or just another dime-a-dozen hack job whose disk will be used as a 
Frisbee at the next family picnic. 


Graphic Design 

There’s a good reason why so many computer game packages are covered 
with exciting illustrations and awe-inspiring screen shots. In spite of how 
hard people try to make intelligent buying decisions, everyone is swayed by 
clever packaging. Although your smart side may tell you to ignore that fabu- 
lous wizard on the box cover, your impulsive side sees that wizard as just a 
hint of the excitement that you'll find in the box. Of course, reality usually 
falls far short of packaging. Buyer beware. 


The lesson here is not that you should make your games look better than 
they play, but rather that how a game looks is often as important as how well 
it performs. You want your gaming screens to be neat and uncluttered, logi- 
cally laid out, and, above all, exciting to look at. Your screens should scream 
“Play me!” to anyone who comes into viewing distance. 


Like anything else, graphic design is a professional skill that takes many years 
of study and practice to master. Luckily, you don’t have to be a graphic- 
design whiz to create attractive game screens. You can look at other games to 
get design ideas. You can also experiment with different screen designs to see 
which are the most attractive and which work best with your game world. 
Use your favorite paint program to draw different layouts and compare them. 
Trial and error is not only a powerful technique for devising improved 
designs, but it’s also a great learning tool. The more you experiment, the 
more you'll learn about what looks good on a computer screen and what 
doesn’t. 


Sound Generation 

The word we live in is a noisy place, indeed. There’s hardly a moment in our 
lives when we’re not assaulted by hundreds of sounds simultaneously. If your 
game world is to seem realistic to the player, it too must provide sound. 
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That’s not to say that you must recreate the full spectrum of sounds heard in 
the real world. With today’s computers, that task would be impossible. Any- 
way, who wants to hear a dog bark or a phone ring in the middle of a game 
of Commander Dweeb and the Nasty Neptunium Ninjas? 


Although you shouldn’t fill your player’s ears with unnecessary noise, you 
should provide as many sound cues as appropriate. When the player strikes a 
monster with a sword, the monster should shriek in pain (or, at least, grunt 
with annoyance). Similarly, when the player slams a home run, she should 
hear the crack of the bat and the roar of the crowd. (That’s so much better 
than the roar of the bat and the crack of the crowd.) 


There’s not a computer game on the planet (or, I’d venture to say, in the 
universe) that could not be improved by better sound effects. Luckily, with 
powerful sound cards such as the Sound Blaster, many of today’s games in- 
clude fabulous digitized sound effects. And, although sound cards can be 
notoriously difficult to program, Windows programmers can take advantage 
of Windows’ device independence to shield them from the complexities of 
sound-card programming. In fact, Windows programmers can play digitized 
sound effects with a single function call, as you'll see later in this book. 


Music, although less important than sound effects, can also add much toa 
computer game. The most obvious place for music is at the beginning of the 
game, usually accompanying a title screen. You might also want to use music 
when the player advances to the next level, or when he accomplishes some 
other important goal in the game. 


Adding music to a computer game, however, requires that you have some 
knowledge of music composition. Bad music in a game is worse than none at 
all. If you have no musical training, chances are that you have a friend who 
does. You can work together to compose the music for your computer game 
magnum opus. If you’re lucky, she won’t even ask for a share of the royalties! 


Controls and Interfaces 

Everything that happens in a computer game happens inside the computer. 
Unlike a conventional board game in the real world, the player can’t use his 
hands to pick up pieces and move them around. To enable the player to con- 
trol the game, the programmer must provide some sort of interface that the 
player can use to manipulate the data that exists inside the computer. In a 
Windows computer game, menus and on-screen buttons enable the user to 
select options and commands. In addition, the keyboard or mouse acts as the 
player’s hands, enabling him to move and otherwise manipulate objects on 
the screen. 
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A good game interface makes playing the game as easy as possible. The com- 
mands that the player needs to control the game should be logical and 
readily available. Also, the more you can make your game work like a real- 
world game, the easier it will be for the player to learn its controls. For ex- 
ample, in a computer chess game, you should enable the player to move a 
game piece with her mouse pointer instead of forcing her to use her keyboard 
to type the square to which she wants to move the piece. 


Image Handling 

Every computer game must deal with various types of images. These images 
may be full-screen background graphics, icons that represent game com- 
mands or game pieces, or tiles that you use to create a map or other complex 
game screen. When you design your game, you must decide which types of 
images you need. Should you draw your program’s background screen at run 
time? Or should you create the screen with a paint program and just load it 
in your program? If you need to conserve memory, should you create your 
game screens from small tiles? 


You must consider questions such as these as you design your computer 
game’s graphics. You want your game to use enough quality graphics to look 
as professional as possible (which means that you may need to find an artist), 
but you also must consider the amount of memory the graphics will consume 
and how long it takes to move graphic images from the disk to the com- 
puter’s memory. Most gamers hate to wait for files to load from a disk. On 
the other hand, keeping too much data in memory may make your game 
incompatible with computers that have smaller amounts of free memory. 


Another important issue is the amount of time it takes to create your game’s 
graphics. You can’t spend the next 10 years drawing detailed graphics for 
every aspect of your game. You need to use shortcuts (such as tiling, which is 
using small graphical images to piece together a game screen) to speed up the 
graphic design process. In other words, although every tree in the real world 
looks different, every tree in a computer game usually looks identical. 


Animation 

After you learn to design and manipulate computer graphic images, you’re 
ready to take the next step: animation. Animation is the process of making 
objects appear to come to life and to move around the computer screen. By 
using a series of images, you can make a chicken waddle across a road, a rock 
tumble from a cliff, or a spaceship blast off from a launch pad. 


Because animation consumes much of your computer’s power and requires 
that you design two or more images of each object you want to animate, you 
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don’t want to go overboard with this programming technique. However, a 
few clever animation sequences can add a lot to an otherwise static game 
screen. 


For example, when a player moves a game piece, instead of having the piece 
simply disappear from its current location and reappear at its new one, you 
might make the piece seem to dissolve and then reform itself. Or, if the play- 
ing piece represents a human being or an animal, you could have the piece 
saunter over to its new location. 


Such simple animation effects can make your game much more interesting 
and even more fun to play. Although animation requires a lot of work on the 
programmer’s part, it’s well worth the effort. 


Algorithms 

Although the term algorithm sounds like the most horrid techno-babble, it’s 
really a simple word. An algorithm is nothing more than a series of steps that 
solves a problem. You use algorithms every day of your life. When you make 
pancakes for breakfast, you must follow an algorithm. When you drive to 
work, you must follow another algorithm. Algorithms enable you to solve all 
of life’s simple (and sometimes not-so-simple) tasks. 


Computer algorithms enable you to solve computing problems. In other 
words, to write computer games, you need to be able to figure out how to get 
your computer to do things—things that you may not have tried to do on a 
computer before. How, for example, can you determine who has the best 
hand in a poker game, or create a smart computer player? You must write an 
algorithm. Once you know how to solve a problem with your computer, you 
can write the specific code in whatever programming language you’re using. 


Artificial Intelligence 

Artificial intelligence routines are algorithms that make computers seem 
smart. By smart, I don’t mean the ability to calculate the player’s score or 
process a player’s input. I mean instead a computer's ability to act as an op- 
ponent. If you want to write a computer game that features computer players, 
you must create algorithms that enable the computer to compete with hu- 
man players. How involved this algorithm turns out to be depends on how 
complex the game is and how well you want the computer to play. 


For example, good algorithms for creating a computer chess player can be 
difficult to write, because winning a game of chess requires a great deal of 
strategy. On the other hand, an algorithm for a computer chess player can 
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also be easy to write. For example, you can simply have the computer choose 
a random move each turn, although such an algorithm yields a computer 
player that’s easy to beat. As you can see, the algorithm that you write can 
determine the difficulty of your game. 


Game Testing 

After you read this book and learn how to design and program your Windows 
computer game, you’ll get to work (I hope) on your own masterpiece. How- 
ever, after you write your game, you’re far from finished, because you then 
must test it extensively to ensure that it works properly. 


The best way to test a game is to give it to a few trusted friends and watch as 
they play, taking notes about things that don’t work quite the way you ex- 
pect. Remember to watch not only for program bugs (things that make the 
program do unexpected things and maybe even crash the computer) but also 
interface bugs, which may make your program confusing to use. 


After your friends have played the game for a while, ask them what they liked 
or didn’t like. Find out how they think the game could be improved. You 
don’t have to agree with everything they say, but always be polite, taking 
their suggestions seriously and writing them down so that you can review 
them later. Don’t be defensive. Your friends aren’t criticizing your work so 
much as they are helping you to make it better. Remember: There’s no such 
thing as a perfect computer program. There’s always room for improvement. 
After the testing is complete, implement the suggestions that you think are 
valuable. 


The only way to test a game is to have several people play it repeatedly. Of 
course, before you pass the game on to a few close friends, you should have 
already played the game so much that you would rather read a phone book 
from cover to cover than see your opening screen again! 


Summary 


Writing a computer game for Windows requires that you bring into play the 
best of your programming skills. To create a successful game, you must first 
design it. This means that you must think about, experiment with, and fi- 
nally implement the game’s graphic design and interface. As you design your 
game, you need to consider the types of images and sounds that will bring 
the game to life. Animation and smart algorithms will also help your game be 
the next best-seller. 
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Now that you know something about the art of game programming, in Chap- 
ter 2 you learn about device-independent bitmaps, which are graphical images 
that are used extensively in Windows (and WinG) programming. You also 
start learning how to use Visual C++’s Visual Workbench to create Windows 
programs. 


Chapter 2 
Manipulating Device- 
Independent Bitmag 


If you’ve done any Windows programming, you know that bitmaps are every- 
where. This is because the BMP graphics format is the only graphical-image 
format (not including icons, which are very limited) that Windows directly 
supports. Look through your Windows programming manuals, and you'll 
find functions such as CreateBitmap(), LoadBitmap(), StretchDIBits(), and 
BitBlt(), which enable you to create, load, or display bitmaps on the screen, 
but you won’t find similar functions for other graphics formats like PCX, TIF, 
and GIF. 


Obviously, then, you can’t get too far with Windows game programming 
without knowing how to handle bitmaps. And, if you’ve programmed under 
Windows before and are tempted to skip this chapter, don’t. The bitmaps you 
previously dealt with under Windows were probably device-dependent 
bitmaps. Unless you know how to program with device-independent bitmaps, 
read on. 


Device-Dependent versus 
Device-Independent 


Device-dependent bitmaps are graphical images that can be displayed on only 
one type of physical device. For example, when you use Windows functions 
such as CreateBitmap() and LoadBitmap(), you’re creating in memory a bitmap 
image that is compatible with a certain device, usually the screen. These types 
of bitmaps are also sometimes called GDI bitmaps, because Windows’ GDI 
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(Graphical Device Interface) can handle them directly. Device-dependent 
bitmaps are stored without color tables because they use the colors of their 
associated device. Moreover, device-dependent bitmaps usually reside only in 
memory, rather than as files on a disk. 


Device-independent bitmaps are graphical images that can be displayed on 
many different devices. These types of bitmaps carry with them a color table 
that the current device must use to display the bitmap, so that the bitmap 
looks similar from one device to another. For example, a device-independent 
bitmap should look almost the same under Windows as it does under DOS or 
OS/2. Because device-independent bitmaps are generally portable between 
systems, you often find them as disk files. For example, if you look in your 
Windows directory, you’ll see many files that have the BMP extension. 
These are device-independent bitmaps. You can create your own device- 
independent bitmaps using various types of paint programs, including 
Windows Paintbrush, which comes with every copy of Windows. You can 
also use Visual C++’s bitmap editor. 


Because device-independent bitmaps (frequently called DIBs) are so versatile, 
this book uses them almost exclusively as the graphical-image file format of 
choice. More importantly, the WinG library, which makes powerful Windows 
games possible, uses this bitmap format extensively. 


The DIB Format 


Whether a DIB is stored on disk or in memory, it has almost exactly the same 
structure. Actually, a DIB is made up of several different types of structures, 
one following the other. These structures include the BITMAPFILEHEADER, 
BITMAPINFO, BITMAPINFOHEADER, and RGBQUAD types. The following sections de- 
scribe these structure types and how they’re used in Windows programs. 


The BITMAPFILEHEADER Structure 
At the beginning of a DIB file is the BITMAPFILEHEADER structure, which is 
defined by Windows as follows: 


typedef struct tagBITMAPFILEHEADER { 
WORD bfType; 
DWORD bfSize; 
WORD bfReserved1 ; 
WORD bfReserved2; 
DWORD bfOffBits; 
} BITMAPFILEHEADER ; 
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Although this structure resides at the beginning of a bitmap disk file, it need 
not be part of the bitmap in memory. The first structure member, bfType, 
identifies the file as a bitmap and should be the ASCII codes of the letters BM. 
In hex, the bfType word should be 4D42. Otherwise, the file is probably not a 
bitmap. The second member, bfSize, is supposed to be the size of the bitmap 
file in bytes. However, due to a mistake in the original Windows documenta- 
tion, bfSize is not reliable and should be ignored. On the other hand, you 
can count on the bfoffBits member to contain the number of bytes from the 
start of the bitmap file to the bitmap data. The BITMAPFILEHEADER structure is 
summarized in table 2.1. 


Table 2.1 The BITMAPFILEHEADER Structure 


Member Type Description 

bfType WORD Contains the ASCII values “BM” 
bfSize DWORD The size of the file 
bfReserved1 WORD Always 0 

bfReserved2 WORD Always 0 

bfOffBits DWORD The number of bytes from the 


beginning of the file to the bitmap 


The BITMAPINFO Structure 
Following the BITMAPFILEHEADER structure is the BITMAPINFO structure, which is 
defined by Windows as follows: 
typedef struct tagBITMAPINFO { 
BITMAPINFOHEADER bmiHeader; 


RGBQUAD bmiColors[1]; 
} BITMAPINFO; 


As you can see, this structure is made up of a header, represented by the 
BITMAPINFOHEADER structure, and a color table, represented by an array of 
RGBQUAD structures. 


The BITMAPINFOHEADER Structure 


A BITMAPINFOHEADER structure, also defined by Windows, looks like this: 


typedef struct tagBITMAPINFOHEADER { 
DWORD biSize; 
DWORD biWidth; 
DWORD biHeight; 
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WORD biPlanes; 

WORD biBitCount; 

DWORD biCompression; 

DWORD biSizeImage; 

DWORD bixXPelsPerMeter; 

DWORD biYPelsPerMeter ; 

DWORD biClrUsed; 

DWORD biClrImportant; 
} BITMAPINFOHEADER ; 


The member biSize contains the size of the BITMAPINFOHEADER structure, 
which should be 40 bytes. The members biwidth and biHeight are the width 
and height of the bitmap in pixels. The member biPlanes is always set to 1. 
The biBitCount member, which indicates the number of bits per pixel, can be 
1, 4, 8, or 24, which indicate monochrome, 16-color, 256-color, and 16.7 
million-color images. (In this book, you mostly use 256-color, or 8-bit, 
images.) 


The biCompression member indicates the type of compression used with the 
bitmap image, where a 0 indicates no compression, a 1 indicates RLE-8 com- 
pression, and a 2 indicates RLE-4 compression. If you’re not familiar with 
data compression techniques, don’t worry about it. DIBs are rarely com- 
pressed. You’ll usually find a 0 in the biCompression structure member. 


The biSize member is the size of the bitmap in bytes and is usually used only 
with compressed bitmaps. This value takes into account that the number of 
bytes in each row of a bitmap is always a multiple of four. The rows are pad- 
ded with blank bytes, when necessary, to ensure a multiple of four. However, 
unless you’re writing a program that creates DIBs, you don’t need to deal 
with row padding and the code complications that arise from it. 


The bixPelsPerMeter and biYPelsPerMeter members contain the horizontal 
and vertical number of pixels per meter, but are usually just set to 0. The 
biClrUsed and biClrImportant members, which contain the total number of 
colors used in the bitmap and the number of important colors in the bitmap, 
are also usually set to 0. 


You may have noticed that BITMAPINFOHEADER structure members after 
biBitCount are likely to contain a 0; so, after reading the structure in from the 
disk file, you’ll probably ignore the values stored in these structure members. 
In this chapter, you see how you can calculate any values you need—such as 
the number of colors used in the image—and store those values in the proper 
members for later retrieval. For easy reference, the BITMAPINFOHEADER structure 
is summarized in table 2.2. 


The DIB Format 


Table 2.2 The BITMAPINFOHEADER Structure 


Member Type Description 
biSize DWORD Size in bytes of this structure 
biwidth DWORD Bitmap’s width in pixels 
biHeight DWORD Bitmap’s height in pixels 
biPlanes WORD Always 1 
biBitCount WORD Number of bits per pixel 
biCompression DWORD Compression type: 0 = None, 
1 =RLE-8, 2 = RLE-4 
biSizeImage DWORD Bitmap’s size in bytes 
bixPelsPerMeter DWORD Horizontal pixels per meter 
biYPelsPerMeter DWORD Vertical pixels per meter 
biClrUsed DWORD Number of colors used 
biClrImportant DWORD Number of important colors 


The RGBQUAD Structure 
The final data structure, RGBQUAD, is defined by Windows like this: 
typedef struct tagRGBQUAD { 
BYTE rgbBlue; 
BYTE rgbGreen; 
BYTE rgbRed; 


BYTE rgbReserved; 
} RGBQUAD; 


This structure simply contains the intensities of a color’s red, green, and blue 
elements. Each color in a DIB is represented by an RGBQUAD structure. That is, a 
16-color (4-bit) bitmap has a color table comprised of 16 RGBQUAD structures, 


whereas a 256-color (8-bit) bitmap has a color table containing 256 RGBQUAD 
structures. The exception is 24-bit color images, which have no color table. 


Following a DIB’s BITMAPINFOHEADER structure is the bitmap’s actual image 
data. The size of this data depends, of course, on the size of the image. Figure 
2.1 illustrates the entire layout of a DIB file. 
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Fig. 2.1 
The structure 
of a DIB. 


BITMAPFILEHEADER 


— 


BITMAPINFO 


nal 


BITMAPINFOHEADER 


RGBQUAD[256] 


Introducing the CDib Class 


Although Visual C++ features classes for many graphical objects, you won't 
find one for DIBs. You don’t, of course, necessarily need a special class to 
handle DIBs, but having such a class helps organize your code into reusable 
modules. For that reason, in this chapter you’ll develop a simple class called 
CDib, which reads DIBs from disk into memory and returns important infor- 
mation about the DIB. 


The CDib Class’s Interface 
The cDib class’s interface is represented by its header file, which is shown in 
listing 2.1. 


Listing 2.1 CDIB.H—The CDib Class’s Header File 


TITTITTTT TTA AAA AAA AAA AAA TAA TAA A AAT 
// CDIB.H: Header file for the DIB class. 
PETTITT LATTA ATTA ATTA AAA AAA AAT AAA AAA AAT 


#ifndef _ _CDIB_H 
#define _ _CDIB_H 


class CDib : public CObject 


protected: 
LPBITMAPFILEHEADER m_pBmFileHeader ; 
LPBITMAPINFO m_pBmInfo; 
LPBITMAPINFOHEADER m_pBmInfoHeader ; 
RGBQUAD* m_pRGBTable; 
BYTE* m_pDibBits; 
UINT m_numColors; 


Introducing the CDib Class 


public: 
CDib(const char* fileName) ; 
~CDib(); 


DWORD GetDibSizeImage() ; 

UINT GetDibWidth() ; 

UINT GetDibHeight(); 

UINT GetDibNumColors(); 
LPBITMAPINFOHEADER GetDibInfoHeaderPtr() ; 
LPBITMAPINFO GetDibInfoPtr() ; 

LPRGBQUAD GetDibRGBTablePtr () ; 

BYTE* GetDibBitsPtr() ; 


protected: 
void LoadBitmapFile(const char* fileName) ; 


}; 


#endif 


The CDib class’s data members consist mostly of pointers to the various parts 
of a DIB: 

LPBITMAPFILEHEADER m_pBmFileHeader; 

LPBITMAPINFO m_pBmInfo; 

LPBITMAPINFOHEADER m_pBmInfoHeader; 

RGBQUAD* m_pRGBTable; 

BYTE* m_pDibBits; 
The preceding pointers store the addresses of the DIB’s BITMAPFILEHEADER, 
BITMAPINFO, and BITMAPINFOHEADER structures, as well as the addresses of the 
DIB’s color table and image data. The final data member holds the number of 
colors in the DIB: 


UINT m_numColors; 
Like most classes, CDib has both a constructor and destructor: 


CDib(const char* fileName) ; 
~CDib(); 


As you can see, you can create a CDib object by passing to the CDib construc- 
tor the file name of the bitmap you want to load. 


To enable you to obtain important information about a DIB after it is loaded, 
the CDib class features eight public member functions: 


DWORD GetDibSizeImage() ; 

UINT GetDibWidth() ; 

UINT GetDibHeight() ; 

UINT GetDibNumColors() ; 
LPBITMAPINFOHEADER GetDibInfoHeaderPtr() ; 
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LPBITMAPINFO GetDibInfoPtr(); 
LPRGBQUAD GetDibRGBTablePtr(); 
BYTE* GetDibBitsPtr(); 


Table 2.3 lists each of the public member functions and what it does. 


Table 2.3 The CDib Class’s Public Member Functions 


Name Description 

GetDibSizeImage() Returns the size in bytes of the image. 
GetDibWidth () Returns the DIB’s width in pixels. 
GetDibHeight () Returns the DIB’s height in pixels. 
GetDibNumColors() Returns the number of colors in the DIB. 


GetDibInfoHeaderPtr () Returns a pointer to the DIB’s BITMAPINFOHEADER 


structure. 
GetDibInfoPtr() Returns a pointer to the DIB’s BITMAPINFO structure. 
GetDibRGBTablePtr () Returns a pointer to the DIB’s color table. 
GetDibBitsPtr() Returns a pointer to the DIB’s image data. 


Finally, the CDib class has a single protected member function that it calls 
internally to load a DIB file: 


void LoadBitmapFile(const char* fileName) ; 


You'll never call this member function directly. 


Programming the CDib Class 

The code that defines the CDib class is found in the CDIB.CPP file, which is 
shown in listing 2.2. In this file, each of the functions in the CDib class is 
defined. 


Listing 2.2 CDIB.CPP—The Implementation of the CDib Class 


FAAITIITIA AETIA LAA IAIA EITTIA 
// CDIB.C: Implementation file for the DIB class. 


TITLTTTTTTTTTT TTT TTT TTT TTT TTT TT 


#include "stdafx.h" 
#include "cdib.h" 
#include "windowsx.h" 
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FITLTTTTAT TTT TT TT ATTA TTT TTT TTT TTL 
// CDib: :CDib() 

FITTTTTTTT AAAA TIAA TITTLE ATETEA AA TEH 
CDib::CDib(const char* fileName) 


{ 
// Load the bitmap and initialize 
// the class's data members. 
LoadBitmapFile(fileName) ; 

} 


FILTITTT TTT TTT TTT TATA 
// CDib::~CDib() 
[ILLIA 
CDib: :~CDib() 


// Free the memory assigned to the bitmap. 
GlobalFreePtr(m_pBmInfo) ; 
} 


eee 
// CDib::LoadBitmapFile() 
// 
// This function loads a DIB from disk into memory. It 
// also initializes the various class data members. 
PILETA ALALIIT IIET IILL ATTA AAA AA TA TTL 
void CDib::LoadBitmapFile 

(const char* fileName) 
{ 

// Construct and open a file object. 

CFile file(fileName, CFile::modeRead) ; 


// Read the bitmap's file header into memory. 
BITMAPFILEHEADER bmFileHeader ; 
file.Read((void*)&bmFileHeader, sizeof (bmFileHeader) ) ; 


// Check whether the file is really a bitmap. 
if (bmFileHeader.bfType != 0x4d42) 


{ 
AfxMessageBox("Not a bitmap file"); 
m_pBmFileHeader = 0; 
m_pBmInfo = 0; 
m_pBmInfoHeader = 0; 
m_pRGBTable = 0; 
m_pDibBits = 0; 
m_numColors = 0; 
} 
// If the file checks out okay, continue loading. 
else 
{ 


// Calculate the size of the DIB, which is the 

// file size minus the size of the file header. 
DWORD fileLength = file.GetLength() ; 

DWORD dibSize = fileLength - sizeof (bmFileHeader) ; 


// Allocate enough memory to fit the bitmap. 
BYTE* pDib = 
(BYTE*)GlobalAllocPtr(GMEM_MOVEABLE, dibSize) ; 


(continues) 


23 


24 Chapter 2—Manipulating Device-Independent Bitmaps 


Listing 2.2 Continued 


// Read the bitmap into memory and close the file. 
file.Read((void*)pDib, dibSize) ; 
file.Close(); 


// Initialize pointers to the bitmap's BITMAPINFO 
// and BITMAPINFOHEADER structures. 

m_pBmInfo = (LPBITMAPINFO) pDib; 

m_pBmInfoHeader = (LPBITMAPINFOHEADER) pDib; 


// Calculate a pointer to the bitmap's color table. 
m_pRGBTable = 
(RGBQUAD* ) (pDib + m_pBmInfoHeader ->biSize) ; 


// Get the number of colors in the bitmap. 
int m_numColors = GetDibNumColors() ; 


// Calculate the bitmap image's size. 
m_pBmInfoHeader ->biSizeImage = 
GetDibSizeImage() ; 


// Make sure the biClrUsed field 

// is initialized properly. 

if (m_pBmInfoHeader->biClrUsed == 0) 
m_pBmInfoHeader ->biClrUsed = m_numColors; 


// Calculate a pointer to the bitmap's actual data. 
DWORD clrTableSize = m_numColors * sizeof (RGBQUAD) ; 
m_pDibBits = 

pDib + m_pBmInfoHeader->biSize + clrTableSize; 


} 


LIILIA TTT TTT TTT TATA TTT TTT TTT ATTA TTT ATT 
// CDib: :GetDibSizeImage() 
// 
// This function calculates and returns the size of the 
// bitmap's image in bytes. 
TLITTTTTTTTTT TTT TTT TTT TTT TTT TATA 
DWORD CDib: :GetDibSizeImage() 
{ 
// If the bitmap's biSizeImage field contains 
// invalid information, calculate the correct size. 
if (m_pBmInfoHeader ->biSizeImage == 0) 
{ 
// Get the width in bytes of a single row. 
DWORD byteWidth = (DWORD) GetDibWidth() ; 


// Get the height of the bitmap. 
DWORD height = (DWORD) GetDibHeight(); 


// Multiply the byte width by the number of rows. 
DWORD imageSize = byteWidth * height; 
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return imageSize; 
} 
// Otherwise, just return the size stored in 
// the BITMAPINFOHEADER structure. 
else 
return m_pBmInfoHeader ->biSizeImage; 


} 


FLTTTTTTTTT ATTA ATTA TATA TAA AAA TT 
// CDib: :GetDibWidth() 

// 

// This function returns the width in bytes of a single 

// row in the bitmap. 

TITTTTTTTTT TTT ATLA ATTA TATA AAT ATT AT 
UINT CDib: :GetDibWidth() 

{ 


} 


ELALLA TATA TATA TTT TL 
// CDib::GetDibHeight () 

// 

// This function returns the bitmap's height in pixels. 
[ILILILILIL III ILIITA 
UINT CDib: :GetDibHeight () 

{ 


} 


PETTTLTTTTTT TTT ATTA ATTA AT TL 
// CDib::GetDibNumColors() 

// 

// This function returns the number of colors in the 

// bitmap. 

TITTITTTTTTT TTT TTA TTT ATT TTL 
UINT CDib: :GetDibNumColors() 


return (UINT) m_pBmInfoHeader ->biWidth; 


return (UINT) m_pBmInfoHeader ->biHeight; 


if ((m_pBmInfoHeader->biClrUsed == @) && 
(m_pBmInfoHeader->biBitCount < 9)) 
return (1 << m_pBmInfoHeader ->biBitCount) ; 
else 
return (int) m_pBmInfoHeader ->biClrUsed; 


} 


FULITTTTTTT TAT TTT ATTA ATT TTT TTT TATA TATA TAT 
// CDib: :GetDibInfoHeaderPtr () 
// 
// This function returns a pointer to the bitmap's 
// BITMAPINFOHEADER structure. 
FLTILTTTTTTT TATA TATA TTT TAT TTT TTT TTT TTL 
LPBITMAPINFOHEADER CDib::GetDibInfoHeaderPtr () 
{ 
return m_pBmInfoHeader ; 
} 


(continues) 
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Listing 2.2 Continued . 


TITILTTTTIITT TTT TTT TATA 
// CDib: :GetDibInfoPtr() 

// 

// This function returns a pointer to the bitmap's 

// BITMAPINFO structure. 

FITIITTTTTT TTT TTT TTT ATTA ATTA TILAAT 
LPBITMAPINFO CDib: :GetDibInfoPtr() 

{ 


} 


return m_pBmInfo; 


FITIITTTTTTTT TIINA FETA PETITA LES IATE ITITI AAI 
// CDib::GetDibRGBTablePtr() 

// 

// This function returns a pointer to the bitmap's 

// color table. 

TILTITTTTTI TTT TTT TTT TATA 
LPRGBQUAD CDib: :GetDibRGBTablePtr () 

{ 


} 


[III IIIT IIIT 
// CDib::GetDibBitsPtr() 

// 

// This function returns a pointer to the bitmap's 

// actual image data. 

VASILIT CIANA ALIAL CIANA TAANA LETETT TI CILIATA 
BYTE* CDib::GetDibBitsPtr() 

{ 


} 


return m_pRGBTable; 


return m_pDibBits; 


Loading a DIB into Memory 


First, look at the class’s constructor: 


CDib::CDib(const char* fileName) 


{ 
// Load the bitmap and initialize 
// the class's data members. 
LoadBitmapFile(fileName) ; 

} 


You create a CDib object by calling the CDib class’s constructor with the file 
name of the DIB you want to load. The constructor passes this file name onto 
the protected member function, LoadBitmapFile(), which actually loads the 
bitmap: 


void CDib: :LoadBitmapFile 
(const char* fileName) 
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// Construct and open a file object. 
CFile file(fileName, CFile::modeReadq) ; 


// Read the bitmap's file header into memory. 
BITMAPFILEHEADER bmFileHeader; 
file.Read((void*)&bmFileHeader, sizeof (bmFileHeader) ) ; 


// Check whether the file is really a bitmap. 
if (bmFileHeader.bfType != 0x4d42) 


{ 


} 


AfxMessageBox("Not a bitmap file"); 
m_pBmFileHeader = 0; 

m_pBmInfo = 0; 

m_pBmInfoHeader = 0; 

m_pRGBTable = Q; 

m_pDibBits = Q; 

m_numColors = 0; 


// If the file checks out okay, continue loading. 


else 


{ 


// Calculate the size of the DIB, which is the 

// file size minus the size of the file header. 
DWORD fileLength = file.GetLength() ; 

DWORD dibSize = fileLength - sizeof (bmFileHeader) ; 


// Allocate enough memory to fit the bitmap. 
BYTE* pDib = 
(BYTE*)GlobalAllocPtr(GMEM_MOVEABLE, dibSize) ; 


// Read the bitmap into memory and close the file. 
file.Read((void*)pDib, dibSize) ; 
file.Close(); 


// Initialize pointers to the bitmap's BITMAPINFO 
// and BITMAPINFOHEADER structures. 

m_pBmInfo = (LPBITMAPINFO) pDib; 

m_pBmInfoHeader = (LPBITMAPINFOHEADER) pDib; 


// Calculate a pointer to the bitmap's color table. 


m_pRGBTable = 
(RGBQUAD*) (pDib + m_pBmInfoHeader ->biSize) ; 


// Get the number of colors in the bitmap. 
int m_numColors = GetDibNumColors() ; 


// Calculate the bitmap image's size. 
m_pBmInfoHeader ->biSizeImage = 
GetDibSizeImage() ; 


// Make sure the biClrUsed field 

// is initialized properly. 

if (m_pBmInfoHeader->biClrUsed == 0) 
m_pBmInfoHeader->biClrUsed = m_numColors; 
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// Calculate a pointer to the bitmap's actual data. 
DWORD clrTableSize = m_numColors * sizeof (RGBQUAD) ; 
m_pDibBits = 

pDib + m_pBmInfoHeader->biSize + clrTableSize; 


} 


This code is fairly complex. In fact, it makes up the bulk of the cDib class’s 
code. The other CDib member functions generally return values calculated by 
LoadBitmapFile(). 


First, LoadBitmapFile() constructs a Visual C++ CFile object: 
CFile file(fileName, CFile::modeRead) ; 


This line of code not only constructs a CFile object named file, but also 
opens the file (whose name is passed in the fileName argument) in the read- 
only mode. 


Next, the function declares a BITMAPFILEHEADER structure and reads the DIB’s 
file header into the structure: 


BITMAPFILEHEADER bmFileHeader; 
file.Read((void*)&bmFileHeader, sizeof (bmFileHeader) ); 


The CFile object’s Read() member function requires as arguments a pointer to 
the buffer in which to store the data and the size of the buffer. In this case, 
the buffer is the BITMAPFILEHEADER structure. 


After the preceding lines, the DIB’s file header is stored in the bmFileHeader 
structure. The first task is to check whether the opened file is actually a 
bitmap, which the function does by checking the bfType member for the 
value ®x4D42, which is the ASCII code for the letters “BM”: 


if (bmFileHeader.bfType != 0x4d42) 


{ 
AfxMessageBox("Not a bitmap file"); 
m_pBmFileHeader = 0; 
m_pBmInfo = 0; 
m_pBmInfoHeader = Q; 
m_pRGBTable = 0; 
m_pDibBits = 0; 
m_numColors = 0; 


} 


If the bfType structure member does not contain the right value, the function 
sets all the class’s data members to O and exits. Otherwise, LoadBitmapFile() 
calls the CFile object’s GetLength() member function to get the size of the 
opened file: 


DWORD fileLength = file.GetLength() ; 
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The function then calculates the size of the DIB by subtracting the size of the 
file header from the size of the file: 


DWORD dibSize = fileLength - sizeof (bmFileHeader) ; 


The program uses the resulting value, dibSize, to allocate enough memory in 
which to store the DIB: 

BYTE* pDib = 

(BYTE*)GlobalAllocPtr(GMEM MOVEABLE, dibSize); 

GlobalAllocPtr() is a Windows function that allocates memory and returns a 
pointer to that memory. It requires two arguments: a flag indicating how the 
memory should be allocated and the size of the memory block to be allo- 
cated. Please refer to your Windows programming manual for more informa- 
tion on GlobalAllocPtr(). 


After allocating memory, the function calls the CFile object’s Read() member 
function to read the DIB into memory and then closes the file by calling the 
Close() member function: 

file.Read((void*)pDib, dibSize) ; 

file.Close(); 
At this point, the DIB is stored in memory, and LoadBitmapFile() can now 
calculate the values the class needs. The addresses of the DIB’s BITMAPINFO and 
BITMAPINFOHEADER structures are identical, being the same address as the buffer 
in which the DIB is stored: 


m_pBmInfo = (LPBITMAPINFO) pDib; 
m_pBmInfoHeader = (LPBITMAPINFOHEADER) pDib; 


The function then calculates a pointer to the color table by adding the size of 
the BITMAPINFOHEADER structure to the address of the DIB in memory: 

m_pRGBTable = 

(RGBQUAD* ) (pDib + m_pBmInfoHeader ->biSize) ; 

When doing this type of pointer math, be careful that you’re using the right 
data types. For example, because pDib is a pointer to BYTE, the number of 
bytes stored in biSize is added to this pointer. However, if pDib were defined 
as a pointer to a BITMAPINFO structure, the value biSize*sizeof (BITMAPINFO) 
would be added to pDib. If you don’t understand this, you should review how 
pointer math works. 


Next, the function initializes the m_numColors data member, by calling the 
member function GetDibNumColors(): 


int m_numColors = GetDibNumColors() ; 
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You'll see how GetDibNumColors() works a little later in this chapter. 


The biSizeImage data member of the DIB’s BITMAPINFOHEADER structure is filled 
in by calling yet another CDib member function, GetDibSizeImage(): 


m_pBmInfoHeader ->biSizeImage = 
GetDibSizeImage(); 


Next, if the BITMAPINFOHEADER’s biClrUsed member is 0, LoadBitmapFile() 
initializes it to the correct value, which is now stored in the m_numColors data 
member: 


if (m_pBmInfoHeader ->biClrUsed == 0) 
m_pBmInfoHeader ->biClrUsed = m_numColors; 


Finally, LoadBitmapFile() calculates the address of the DIB’s image by adding 
the size of the BITMAPINFOHEADER structure and the size of the color table to 
the pDib pointer, which contains the address of the DIB in memory. 


DWORD clirTableSize = m_numColors * sizeof (RGBQUAD) ; 
m_pDibBits = 
pDib + m_pBmInfoHeader->biSize + clrTableSize; 


Other CDib Member Functions 

In the previous section, some CDib data members were initialized by calling 
CDib member functions. One of those member functions was 
GetDibImageSize(), which calculates the size of the DIB in bytes: 


DWORD CDib: :GetDibSizeImage() 
{ 
// If the bitmap's biSizeImage field contains 
// invalid information, calculate the correct size. 
if (m_pBmInfoHeader ->biSizeImage == 0) 
{ 
// Get the width in bytes of a single row. 
DWORD byteWidth = (DWORD) GetDibWidth() ; 


// Get the height of the bitmap. 
DWORD height = (DWORD) GetDibHeight() ; 


// Multiply the byte width by the number of rows. 
DWORD imageSize = byteWidth * height; 


return imageSize; 


} 


// Otherwise, just return the size stored in 
// the BITMAPINFOHEADER structure. 
else 

return m_pBmInfoHeader ->biSizeImage; 


} 


This function first checks whether the biSizeImage member of the 
BITMAPINFOHEADER structure already contains a value other than 0: 
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if (m_pBmInfoHeader ->biSizeImage == Q) 
If it does, the function simply returns the value stored in biSizeImage: 
return m_pBmInfoHeader ->biSizeImage; 


Otherwise, the function must calculate the image size using the information 
it already has. 


First, it gets the DIB’s width and height in pixels: 


DWORD byteWidth = (DWORD) GetDibWidth(); 
DWORD height = (DWORD) GetDibHeight(); 


Then, it multiplies the width by the height to get the size of the entire 
bitmap image: 


DWORD imageSize = byteWidth * height; 


Notice that all these calculations are done with DworDs in order to avoid the 
truncation errors that might occur with regular integers. DIBs can be big! 


Another member function that must do some calculations is 
GetDibNumColors(): 


UINT CDib: :GetDibNumColors() 


if ((m_pBmInfoHeader->biClrUsed == 0) && 
(m_pBmInfoHeader->biBitCount < 9)) 
return (1 << m_pBmInfoHeader ->biBitCount) ; 
else 
return (int) m_pBmInfoHeader ->biClrUsed; 


} 


This function first checks the BITMAPINFOHEADER structure’s biClrUsed member 
for a value other than 0. If it finds a value other than 0, it simply returns that 
value from the function. Otherwise, it calculates the number of colors by 
shifting the value 1 to the left, using the biBitCount member as the shift 
count. This results in a value of 2 for 1-bit (monochrome) DIBs, 16 for 4-bit 
DIBs, and 256 for 8-bit DIBs. 


The remaining CDib member functions just return the values of the class’s 
data members. For example, the GetDibRGBTablePtr() function returns a 
pointer to the DIB’s color table, a value that has already been stored in the 
data member m_pRGBTable: 


LPRGBQUAD CDib::GetDibRGBTablePtr () 
{ 


} 


return m_pRGBTable; 
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Fig. 2.2 
The New dialog 
box. 


Creating SHOWDIB, Version 1 


Now that you have a class for handling DIBs, it’s time to put the class to 
work. In this section, you use Visual C++’s AppWizard to create an applica- 
tion that can load and display DIBs. 


Creating the Basic Application 

Thanks to Visual C++’s amazing AppWizard, you can create a basic Windows 
application with very little effort. Once you’ve created the basic application, 
other Visual C++ tools—such as ClassWizard and the resource editors—help 
you flesh out the application to perform exactly the tasks you want it to. In 
this section, you create the SHOWDIB application, which displays DIBs in its 
main window. 


The complete source code and executable file for this step in the creation of the 
SHOWDIB application can be found in the CHAPO2\SHOWDIB1 directory of this 
book’s CD-ROM. ae 


To create the basic SHOWDIB application, follow these steps: 


1. Start Visual C++ and select the File menu’s New command. The New 
dialog box appears, as shown in figure 2.2. 


2. Select Project from the list, and click the OK button. You see the New 
Project dialog box (see fig. 2.3). 


3. In the Project Name edit box, type the project name SHOWDIB, and in 
the Project Path box, select the MSVC20 directory (or whatever direc- 
tory into which you installed Visual C++). Finally, make sure the Project 
Type box has MFC AppWizard selected. 


4. Select the Create button. The Step 1 dialog box appears, as shown in 
figure 2.4. Choose the Single Document option. 
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[New Proiect TRER z E Fig. 2.3 

The New Project 
dialog box. 

[MFC AppWizard } er Ea Fig. 2.4 

The Step 1 dialog 
box. 

. Click the Next button three times. You see the Step 4 of 6 dialog box. 
Turn off all the features except Use 3D Controls, as shown in figure 2.5. 

I MFC AppWizard - Step 4 of 6 ee Fig. 2.5 

i s The Step 4 of 6 
dialog box. 


SEENI 
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6. Click the Next button twice. The Step 6 of 6 dialog box appears 
(see fig. 2.6). 


Fig. 2.6 
The Step 6 of 6 
dialog box. 

7. Click the Finish button. When the New Project Information dialog box 
appears (see fig. 2.7), click the OK button to close the dialog box and to 
generate the files needed for the project. 

Fig. 2.7 [New Project Information 


The New Project 


Information dialog - 
box. i Brae “Document Intetface Application targeting: 


[Classes to be created: 
Application: CShowdibApp in showdib,h and showdib.cpp 
Frame: CMainFrame in mainfrm.h and mainfrm.cpp 

| Document: CShowdibDoc in showddoc.h and showddoc.cpp 
View: CShowdibView in showdyw.h and showdyw.cpp 


Features: 
+MSYC Compatible project file (showdib.mak) 
+ 3D Controls 
+ Uses shared DLL implementation (MFC30.DLL) 
+ Localizable text in U.S. English 
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8. Select the Project menu’s Rebuild All command to compile and link the 
new SHOWDIB application. 


9. To run the program after it’s compiled, select the Project menu’s 
Execute command. The window shown in figure 2.8 appears. 


Fig. 2.8 
The basic 
SHOWDIB 


F= Untitled 


Modifying SHOWDIB’s Resources 
Now that you have the basic SHOWDIB application created, you can use 
Visual C++’s tools to modify the application to fit your needs. 


The complete source code and executable file for this step in the creation of the 
SHOWDIB application can be found in the CHAPO2\SHOWDIB2 directory of this 
book’s CD-ROM. 


When you create a new application, AppWizard generates a directory called RES that 
contains some of your project’s resources, as well as a directory called WinDebug or 
WinRel (depending on whether you're creating a debugging or release version of the 
program) that contains all the project’s output files. It also generates 15 other files 
that make up the application’s source code. The files AppWizard generates for 
theSHOWDIB project are the following: 


(continues) 


application. 
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1. Double-click the SHOWDIB.RC file in the project window. Visual C++ 
displays the resource browser window, as shown in figure 2.9. 


Fig. 2.9 ™ showdib. re 
The resource yes 
browser window. 
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2. In the browser window, double-click the Menu resource, and then 
double-click the IDR_MAINFRAME menu ID. Visual C++’s menu editor 
appears, as shown in figure 2.10. 


» showdib.rc - IDR_MAINFRAME [Me ) Fig. 2.10 
The menu editor. 


3. Click on SHOWDIB’s Edit menu (not Visual C++’s Edit menu), and then 
press your keyboard’s Delete key to delete the Edit menu. When you do, 
a dialog box asks for verification of the delete command. Click the OK 
button. 


4. Click on SHOWDIB’s File menu (not Visual C++’s File menu). The File 
menu appears, showing its various commands. Using your mouse and 
your keyboard’s Delete key, delete all the File menu’s commands except 
Open and Exit. When you’re done, SHOWDIB’s menus should look like 
figure 2.11. 


EE Fig. 2.11 
SUE SHOWDIB’s new 
menus. 


pwdib.rc - IDR_MAINFRAME (Menu) 


5. Close the menu editor, and then double-click the Accelerator resource 
in the browser window. Double-click the IDR_MAINFRAME accelerator ID 
to bring up the accelerator editor, as shown in figure 2.12. 


6. Using your keyboard’s arrow and Delete keys, delete all accelerators 
except ID_FILE_OPEN, as shown in figure 2.13. 
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Fig. 2.12 
The accelerator 
editor. 


Fig. 2.13 

The accelerator 
editor after you 
delete unneeded 


A showdib.rc - IDR_MAINFRAME (Accelerator) 


ID_FILE_OPEN 
ID_FILE_SAVE 
ID_EDIT_PASTE 
ID_EDIT_UNDO 
1D_EDIT_CUT 

ID_NEXT_PANE 

| ID_PREV_PANE 
ID_EDIT_COPY 
ID_EDIT_PASTE 


ID_EDIT_CUT 
ID_LEDIT_UNDO 


A showdib.rc - IDR_MAINFRAME (Accelerator) 


Ctl+N 

Cti +0 

Cti +S 

Ctl +Y 

Alt + VK_BACK 

Shift + VK_DELETE 

VK_F6 

Shift + VK_F6 

Ctrl + VK_INSERT 

Shift + VK_INSERT VIRTKEY 
Ctl +X VIRTKEY 
Ctrl +Z VIRTKEY 


accelerators. 
7. Close the accelerator editor, and then double-click the Dialog resource 
in the browser window. Double-click the IDD_ABOUTBOX dialog-box ID to 
bring up the dialog-box editor, as shown in figure 2.14. 
Fig. 2.14 [i= showdib.rc - IDD_ABOUTBOX (Dialog) 
The dialog box z7 
editor. 


8. Modify the dialog box by adding the static string "by Macmillan 
Computer Publishing", as shown in figure 2.15. 
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et showdib.1c IDD ABOUTBOX (Dialog) <. EE RES Fig. 2.15 
3 : Modifying the 
About dialog box. 


9. Close the dialog editor and the resource browser window, being sure to 
save your changes. Then select the Project menu’s Build command to 
compile the modified application. 


When you run the newly compiled application, you see the window shown 
in figure 2.16. If you select the File menu’s Open command, the File Open 
dialog box appears, from which you can select a file. When you select a file, 
its name appears in the window in place of the “Untitled” string, as shown in 
figure 2.17. If you select the Help menu’s About Showdib command, you see 
the About dialog box (also shown in figure 2.17) that you modified in the 
dialog editor. 


Fig. 2.16 
SHOWDIB after 
compiling new 
resources. 
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Fig. 2.17 
SHOWDIB after 
opening 
MAINFRM.CPP 
and displaying the 
new About dialog 
box. 


showdib Version 1.0 


AFX Copyright © 1995 
by Macmillan Computer Publishing 


Adding Code to SHOWDIB, Version 1 
After you’ve edited the application’s resources, SHOWDIB’s user interface is 
complete. However, the program is still incapable of loading and displaying 
DIBs. Even when you use the Open command to select a DIB file, nothing 
happens (except that the DIB’s file name appears in the window’s title bar). 
The next step, then, is to add the code needed to make SHOWDIB do what 
you want it to do. The following steps describe how to add this code to the 
application. If you like, you can refer to listings 2.3 through 2.7 to verify code 
placement. In those listings, code that you add is placed between double lines 
of slash characters with the comment START CUSTOM CODE or END CUSTOM CODE 
between them. For example, 

TLTTLTTITTTTT TTT TTT TATA TTA ATELE EETA 

TITTTTTTTT TTT TATA TATA ATA TL 

// START CUSTOM CODE 


[IILI IIIA TAT TT 
[IIIIIIII I IIIA 


#include "cdib.h" 


TATLILARA EEEE TL 
PICIT CELITA ATATIA CELA TELELA 
// END CUSTOM CODE 

AIIP TATANA AAN CIEE AAAA 
PIISAS TECELANA TELFERA E AA 


indicates that you must manually add the line #include "cdib.h" to the 
listing. 
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1. Select the Project menu’s ClassWizard command. The MFC ClassWizard 
dialog box appears, as shown in figure 2.18. 


: MFC ClassWizard TEA TOET EEI SECS Fig. 2.18 
GEES S| The MFC 
ClassWizard 
dialog box. 


2. In the Class Name box, select the CMainFrame class. Then, select 
CMainFrame in the Object IDs list box, and double-click PrecreateWindow 
in the Messages list box. 


3. Click the Edit Code button to open the source code window to this new 
function, and add the following lines, right after the // TODO: Add your 
specialized code here and/or call the base class comment: 


4. Copy the CDIB.CPP and CDIB.H files into SHOWDIB’s project direc- 
tory. (You'll find CDIB.CPP and CDIB.H on this book’s CD-ROM, in the 
CHAP02\SHOWDIB directory.) 
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Fig. 2.19 
Adding CDIB.CPP 
to the SHOWDIB 
project. 


5. 


6. 


Select the Project menu’s Files command. The Project Files dialog box 
appears, as shown in figure 2.19. In the File Name list box, double-click 
the CDIB.CPP file to add it to the project, and then click the Close but- 
ton to finalize your choice. 


Project Files 


Load the SHOWDDOC.H file and add the following line to the top of 
the source code, right before the declaration of the CShowdibDoc class: 


#include "“cdib.h" 


This line includes the cDib class’s declaration into the SHOWDIB 
application’s document header file, so that you can use the CDib class in 
the document class. 


In SHOWDDOC.H, add the following line to the Attributes section of 
the CShowdibDoc class’s declaration, right after the public keyword. 


CDib* m_pDib; 


This line declares a pointer to a CDib object as a data member of the 
CShowdibDoc class. The CDib object represents whatever DIB the applica- 
tion is currently displaying. 


In the SHOWDDOC.CPP file, add the following line to the class’s con- 
structor, after the // TODO: add one-time construction code here com- 
ment: 


m_pDib = ð; 


This line ensures that the cDib pointer starts off at 0. 


10. 


11. 


12. 
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Select the Project menu’s ClassWizard command. The MFC ClassWizard 
dialog box appears (refer to fig. 2.18). 


In the Class Name box, select the CShowdibDoc class. Then, click 
ID_FILE_OPEN in the Object IDs box, and double-click COMMAND in 
the Messages box. The Add Member Function dialog box appears. 


Click the OK button to add the OnFileOpen() function to the class. Click 
the Edit Code button to open the source code window to this new 
function. 


Add the following code to the new OnFileOpen() function, after the 
// TODO: Add your command handler code here comment: 


// Construct an Open dialog-box object. 
CFileDialog fileDialog(TRUE, "bmp", "*.bmp"); 


// Display the Open dialog box. 
int result = fileDialog.DoModal(); 


// If the user exited the dialog box 
// via the OK button... 
if (result == IDOK) 


{ 
// Get the selected path and file name. 
CString string = fileDialog.GetPathName() ; 
// Construct a new CDib object. 
m_pDib = new CDib(string); 
// Check that the CDib object was created okay. 
// If there was an error, the pBmInfo pointer 
// will be @. 
LPBITMAPINFO pBmInfo = m_pDib->GetDibInfoPtr(); 
// If the CDib object was not constructed 
// properly, delete it. 
if (!pBmInfo) 
DeleteContents(); 
// Otherwise, set the document's title to 
// the DIB's path and file name. 
else 
SetTitle(string) ; 
} 


// Notify the view object that it has new data to display. 
UpdateAllViews (0); 


The OnFileOpen() function will now respond to the File menu’s Open 
command, not only by enabling the user to select a file, but also by 


43 


44 Chapter 2—Manipulating Device-Independent Bitmaps 


13. 


14. 


15. 


creating a new CDib object from the selected DIB. This function is dis- 
cussed in detail later in this chapter. 


Select the Project menu’s ClassWizard command. When the MFC 
ClassWizard dialog box appears, select the CShowdibDoc class in the Class 
Name box, click on CShowdibDoc in the Object IDs box, and double-click 
DeleteContents in the Messages box to add the virtual DeleteContents() 
function. 


Click the Edit Code button to jump to the DeleteContents() function, 
and add the following code to the function, after the // TODO: Add your 
specialized code here and/or call the base class comment: 

// If there's a valid CDib object, delete it. 

if (m_pDib) 

: delete m_pDib; 

m_pDib = 0; 

} 
The DeleteContents() function overrides the CDocument base class’s 
DeleteContents() function. MFC calls this function whenever the appli- 
cation needs to delete the current document’s data. Because 
DeleteContents() is also called when a new document is created (to 
ensure that the new document is empty), you must check that m_pDib is 
not @ before you delete it. 


Open the SHOWDVW.CPP file and add the following code to the 
OnDraw() function, right after the // TODO: add draw code for native 
data here comment: 


// Get a pointer to the current CDib object. 
CDib* pDib = pDoc->m_pDib; 


// If the CDib object is valid, display it. 
if (pDib) 
{ 
// Get a pointer to the DIB's image data. 
BYTE* pBmBits = pDib->GetDibBitsPtr(); 


// Get a pointer to the DIB's info structure. 
LPBITMAPINFO pBmInfo = pDib->GetDibInfoPtr(); 


// Get the DIB's width and height. 
UINT bmWidth = pDib->GetDibWidth() ; 
UINT bmHeight = pDib->GetDibHeight() ; 
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// Display the DIB. 
StretchDIBits(pDC->m_hDC, 
10, 10, bmWidth, bmHeight, 
©, ©, bmWidth, bmHeight, 
pBmBits, pBmInfo, DIB _RGB_COLORS, SRCCOPY) ; 
} 


MFC calls the OnDraw() function whenever the application’s main win- 
dow must be redrawn. The preceding code, which is described in detail 
later in the chapter, displays the currently loaded DIB. 


16. Select the Project menu’s Build command to compile and link the new 
version of the SHOWDIB application. 


You may be somewhat confused about what all the different classes in the SHOWDIB 
application do. Here’s a description. The CShowdibApp class (declared and defined in 
the SHOWDIB.H and SHOWDIB.CPP files) represents the program’s application 
object. Every Visual C++ MFC program must have an application object. The 
CMainFrame class (MAINFRM.H and MAINFRM.CPP) represents the application’s 
frame window. The frame window is the window you see when you start the 
application. 


The CShowdibDoc class (SHOWDDOC.H and SHOWDDOC.CPP) represents the 
application’s document class. In a Visual C++ program, the document class holds the 
data that makes up the current document, such as the text in a word processor 
document. Finally, the CShowdibView class (SHOWDVW.H and SHOWDVW.CPP) 
represents the application’s view. In a Visual C++ program, the view is responsible 
for displaying the data stored in the document class. The view also enables the user 
to change the document, although that feature is not used in the SHOWDIB 
application. 


Version 1 of SHOWDIB is now complete. Before you run the application, 
however, read the following sections, which explain how the OnFileOpen() 
and OnDraw() functions work. 


Examining the OnFileOpen() Function 

As you were putting together the first version of the SHOWDIB application, 
there were a couple of functions that needed further explanation. One of. 
those functions was OnFileOpen(). 
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Normally, an application created by AppWizard responds to the File menu’s 
Open command by displaying an Open dialog box and then calling the docu- 
ment class’s Serialize() function, which loads the requested data. You saw 
this happen when you ran the basic version of SHOWDIB. 


Unfortunately, because SHOWDIB requires some special file handling, it 
doesn’t take advantage of the Serialize() function. Instead, the program 
uses the OnFileOpen() function to load a DIB. Because you “attached” this 
function to the File menu’s Open command, MFC calls it whenever a file 
needs to be opened. 


The function’s first task is to display the Open dialog box so that the user can 
choose the file she wants to view: 


CFileDialog fileDialog(TRUE, "bmp", "*.bmp") ; 


MEC encapsulates the Open dialog box in the CFileDialog class. To construct 
a CFileDialog object, call its constructor with three arguments: the Boolean 
value TRUE, a string containing the default file extension, and a string con- 
taining the initial file name to appear. 


Once you've constructed a new CFileDialog object, display the dialog box by 
calling the class’s DoModal() member function: 


int result = fileDialog.DoModal() ; 


The function DoModal() returns the ID of the button used to exit the dialog 
box. If that ID equals ID_OK, the user has selected a valid file name. In that 
case, OnFileOpen() gets the selected file name by calling the file dialog’s 
GetPathName() member function: 


CString string = fileDialog.GetPathName() ; 


The program then uses the returned file name to construct a new CDib object, 
which, as you already know, also loads the DIB into memory. If CDib’s con- 
structor cannot load the DIB, it sets all the CDib object’s data members to 0. 
So, to check whether the DIB was loaded okay, OnFileOpen() calls the CDib 
object’s GetDibInfoPtr() function to get a pointer to the DIB’s BITMAPINFO 
structure: 


LPBITMAPINFO pBmInfo = m_pDib->GetDibInfoPtr(); 


If the returned pointer is @, the DIB was not loaded, and the program calls 
DeleteContents() to delete the unusable CDib object: 
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if (!pBmInfo) 
DeleteContents(); 
Otherwise, the program calls the document object’s SetTitle() member func- 
tion to set the window’s title to the DIB’s file name: 


SetTitle(string) ; 


SetTitle()’s single argument is a string containing the window’s new title, in 
this case, the string returned from the dialog object’s GetPathName() function. 


Because the window now has a new DIB to display, OnFileOpen() calls the 
document object’s UpdateAllViews() member function, to tell the view object 
that it must redraw the window: 


UpdateAllViews (0); 


This function call’s single parameter is a pointer to the view object that modi- 
fied the document. Because, in this case, the document itself changed its 
contents, this argument should be 0, which indicates that all views should be 
updated. 


Examining the OnDraw() Function 

Another function you need to look at in more detail is the view object’s 
OnDraw() function, which is responsible for updating the main window’s 
display. In the SHOWDIB application, OnDraw() must display the currently 
selected DIB. 


Because the CDib object is part of the document class, OnDraw() first gets a 
pointer to the CDib object, accessing the document object through the pDoc 
pointer supplied by OnDraw(). (The code that supplies this pointer was gener- 
ated by AppWizard.) As you can see, pDoc points to the application’s docu- 
ment object: 


CDib* pDib = pDoc->m_pDib; 


If the application has loaded a DIB (pDib is not 0), OnDraw() gets pointers to 
the DIB’s image and BITMAPINFO structure: 


BYTE* pBmBits = pDib->GetDibBitsPtr(); 
LPBITMAPINFO pBmInfo = pDib->GetDibInfoPtr(); 


The function also gets the DIB’s width and height: 


UINT bmWidth = pDib->GetDibWidth(); 
UINT bmHeight = pDib->GetDibHeight() ; 


47 


48 Chapter 2—Manipulating Device-Independent Bitmaps 


The program then displays the DIB by calling the Windows function 
StretchDIBits(): 
StretchDIBits(pDC->m_hDC, 
10, 10, bmWidth, bmHeight, 


©, ©, bmWidth, bmHeight, 
pBmBits, pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


This function requires a whopping 13 arguments. The first argument is a 
handle to the destination device context (that is, the device context onto 
which the DIB should be displayed). Because OnDraw() supplies a pointer to 
the destination device context (DC), you must use this pointer to access the 
DC’s handle, which is stored in the DC class’s m_hDC data member. 


In order to display data, a Windows application must obtain something called a 
device context. Despite its fancy name, a device context is really little more than a 
collection of attributes that describe how data is to be displayed in a window. These 
attributes include pen colors and sizes, brush colors and sizes, fill colors, and other 
important graphical information. 


In a normal Windows program, you'd be responsible for creating and managing a 
device context whenever you wanted to display something on the screen. However, 
Microsoft Foundation Classes takes care of much of the dirty work for you. In func- 
tions like OnDraw(), MFC supplies the device context as one of the function’s param- 
eters. For more information on device contexts and MFC’s device-context classes, 
refer to your Windows and Visual C++ documentation. 


The next four arguments are the X coordinate, Y coordinate, width, and 
height of the destination rectangle. This rectangle is the area of the destina- 
tion DC into which you want to copy the DIB. The next four arguments de- 
fine the source rectangle. In this case, because you want to display the entire 
DIB, this rectangle has X,Y coordinates of 0,0 and is the same width and 
height as the DIB. 


The ninth and tenth arguments are pointers to the DIB’s image data and 
BITMAPINFO structure. The eleventh argument is a flag that describes the colors 
used with the DIB. The flag DIB_RGB_COLORS means that the DIB’s color table 
contains actual RGB values, whereas the DIB_PAL_COLORS flag indicates that 
the color table contains 16-bit indexes into the logical palette. (You learn 
about logical palettes later in this chapter.) Finally, the last argument is a flag 
that tells the function how to combine the source and destination rectangles. 
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In this case, SRCCOPY means that the source rectangle should overwrite the 
destination rectangle. 


Now that you know how the program works, it’s time to try it out. 


Running Version 1 of SHOWDIB 

The SHOWDIB application can now load and display a DIB. To use the pro- 
gram, select the File menu’s Open command and select a DIB file. SHOWDIB 
loads the selected DIB and displays it in its main window. Figure 2.20 shows 
the results when you select the DOGGIE2.BMP file, which is included with 
the WinG Developer’s Kit and is also found on this book’s CD-ROM, in the 
CHAP02\SHOWDIB directory. 


= C:\MSVC20\Showdib\D oggie2.bmp - showdib ese S Fig. 2.20 
S SHOWDIB displays 
a bitmap. 


When using this first version of SHOWDIB, you’ll probably notice that, al- 
though the program can load and display a DIB, the resulting display some- 
times looks pretty weird. This is because, currently, SHOWDIB ignores the 
DIB’s color table. In order to display a DIB correctly, a program must create a 
logical palette from the DIB’s color table and then select that palette before 
actually updating the display window. Because dealing with logical palettes is 
a big topic under Windows, it has its own section in this chapter. In the next 
section, then, you'll add palette-handling features to SHOWDIB so that it can 
display DIBs using the correct colors. 
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Currently, SHOWDIB cannot display a DIB properly because it does not set 
Windows’ colors to those that were used to create the DIB. The colors you 
need are found in the DIB’s color palette. In order to display the DIB prop- 
erly, you must create a logical palette from the DIB’s color table, and then 
realize that palette before displaying the DIB. When you realize a palette, 
you're telling Windows to change its colors to those you've defined in the 
logical palette. 


But what exactly is a logical palette? Every application that must define colors 
has its own logical palette. When the user switches between applications, the 
new application gives its logical palette to Windows so that Windows can set 
its colors properly. A logical palette, then, is a set of colors that’s associated 
with a particular application. The system palette, on the other hand, contains 
the colors that are currently displayed on the screen. When a user switches 
applications, the new application’s logical palette is mapped into Windows’ 
system palette. You can have many logical palettes, but there is never more 
than one system palette. 


The process by which Windows maps a logical palette into the system palette, 
however, is complex and cause for much confusion. That’s why you see so 
little about palettes in most Windows programming books. But, as you may 
have guessed, if you are going to display DIBs (not to mention use the WinG 
library successfully), you must know how Windows palettes work. 


Mapping between a Logical and a System Palette 
When an application realizes a logical palette, Windows must map the 
application’s palette to the system palette. Because there is only one system 
palette—and because that system palette must be shared by every currently 
running application—mapping a logical palette is not as simple as copying 
the logical palette to the system palette. While taking this easy way out 
would work well for the active application, any applications running in the 
background may end up with bizarre displays. When Windows maps palettes, 
it must do its best to keep every application’s display looking as good as pos- 
sible. Windows follows these steps to set an application’s requested colors: 


1. Exactly match colors in the logical palette to existing colors in the system 
palette. This step requires that no colors in the system palette be modi- 
fied, which, of course, also ensures that other applications retain their 
own colors. 
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2. Use empty system palette entries to create colors for those logical palette en- 
tries that could not be matched in step 1. By using empty system palette 
entries (entries not being used by any other application), Windows 
again ensures that colors used by other applications remain unaffected. 


3. Match remaining entries in the logical palette to the closest color in the system 
palette. Obviously, with many applications vying for colors, the system 
palette may become filled. When this happens, Windows can no longer 
plug colors from a logical palette into empty system palette entries. At 
this point, a background application’s display suffers some degradation, 
depending on how closely the selected colors match the application’s 


palette. 


Although Windows follows the preceding rules when mapping colors, the 
order in which each application is handled is obviously important. For this 
reason, Windows maps the active application’s colors first, after which it 
maps background applications’ colors starting with the most recently active 
and working its way back to the least recently active. 


Need an example? For the sake of simplicity, suppose that the system palette 
can display only 10 colors. Suppose also that you have two applications run- 
ning—App1 and App2—each of which has realized a six-color palette. Before 
any mapping occurs, the palettes look like figure 2.21. 


System 
Palette 


Fig. 2.21 
App1 Unmapped 


palettes. 
| Red | 


Green 
Yellow 
Brown 


App2 


51 


52 Chapter 2—Manipulating Device-Independent Bitmaps 


Fig. 2.22 
After mapping 
App1’s palette. 


App] is the active application and so Windows maps App1’s colors first. Win- 
dows first maps App1’s black to the system palette’s black, because they are 
an exact match. Then, Windows fills the next five empty system palette en- 
tries with the five remaining colors in App1’s logical palette. After App1’s 
logical palette has been fully realized, the palettes look like figure 2.22. 


System 
Palette App1 


= 
| Red |—— | Red _ 
a 
— 
Yelow |— Yellow 
— 
Empty App2 


Pink 
Blue 


Because App2 is running in the background, Windows maps App2’s colors 
after App1’s. Again, Windows maps black to black because it’s an exact 
match. Next, Windows fills the system palette’s remaining three empty en- 
tries with the next three colors in App2’s palette. Now, the system palette is 
filled. Unfortunately, App2 still has two colors—pink and blue—that need to 
be mapped. Windows now has no choice but to map these two remaining 
colors to the closest colors in the system palette. So, Windows matches pink 
to red and blue to aqua. The palettes now look like figure 2.23. 


After both application’s palettes have been mapped, App1 has exactly the 
colors it needs, whereas App2 has suffered a slight degradation in its display. 
But, because App2 is currently running in the background, its display isn’t as 
important as App1’s. When App2 becomes active, it will get its chance to 
create the display it needs. 
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Now that you know how Windows handles color palettes, it’s time to add 
palette-handling abilities to the SHOWDIB application. You do this in the 
next section. 


The Windows system palette reserves the first 10 and last 10 colors of a 256-color 
palette for its own use. It uses these colors to draw window borders, buttons, menus, 
_and other Windows objects. Normally, you should not attempt to change these 20 
reserved colors. In other words, on a 256-color system running under Windows, you 
really have only 236 colors at your disposal. 


Adding Code to SHOWDIB, Version 2 

You’re now ready to add palette handling to the SHOWDIB application. 
When you're finished with this section, SHOWDIB will display DIBs cor- 
rectly, using the DIB’s color table to create a logical palette for the 
application. 


Fig. 2.23 
After mapping 
App2’s palette. 
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_ The complete source code and cane file for this ste 
SHOWDIB application can be found in the CHAPO2\SHOWDIB4 directory of this 


book’s CD-ROM. 


To add these abilities, follow these steps: 


1. 


Add the following function declaration to the CShowdibView class, found 
in the file SHOWDVW.H. Place the code in the class’s Implementation 
section, right before the // Generated message map functions comment 
and right after the protected keyword. 


HPALETTE CreateDibPalette(CDib* pDib) ; 


The preceding line declares the function CreateDibPalette()—which 
returns a handle to a logical palette—as a protected member function of 
the CShowdibView class. 


Add the following function to the view’s implementation file. Place the 
code at the end of the SHOWDVW.CP?P file, right after the 
// CShowdibView message handlers comment. 


HPALETTE CShowdibView: :CreateDibPalette(CDib* pDib) 

{ 
// Get a pointer to the DIB's color table. 
LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr() ; 


// Get the number of colors in the DIB. 
UINT numColors = pDib->GetDibNumColors() ; 


struct 

{ 
WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256] ; 

} logicalPalette = { 0x300, 256 }; 


// Fill the palette structure with the DIB's colors. 
for(UINT i=0; i<numColors; ++i) 
{ 
logicalPalette.aEntries[i].peRed = 
pColorTable[i].rgbRed; 
logicalPalette.aEntries[i].peGreen = 
pColorTable[i].rgbGreen; 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i] .rgbBlue; 
logicalPalette.aEntries[i].peFlags = 0; 
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// Create the palette object. 
HPALETTE hPalette = 
CreatePalette((LPLOGPALETTE) &logicalPalette) ; 


return hPalette; 
} 
This function creates the application’s logical palette based on the DIB’s 
color table. You examine this function in greater detail later in this 
chapter. 


3. Add the following code to the view’s OnDraw() function. Place the code 
after the if statement’s opening brace: 


// Create the DIB's palette; 
HPALETTE hPalette = CreateDibPalette(pDib) ; 


// Select the DIB's palette into the DC. 
HPALETTE hOldPalette = 
SelectPalette(pDC->m_hDC, hPalette, FALSE); 


// Map the DIB's palette to the system palette. 
RealizePalette(pDC->m_hDC) ; 
The preceding code creates and realizes the application’s logical palette 
before displaying the DIB. You examine this code in greater detail later 
in this chapter. 


` 4. Add the following code immediately after the StretchDIBits() call in 
OnDraw(): 


// Deselect the logical palette from the DC. 
SelectPalette(pDC->m_hDC, hOldPalette, FALSE); 


// Delete the logical palette. 
DeleteObject(hPalette) ; 


This code deletes the logical palette. Later in this chapter, you see why 
deleting the palette is necessary. 


Version 2 of SHOWDIB is now complete. Before you run the application, 
however, read the following sections, which explain how the new code you 
added works. 


Examining the CreateDibPalette() Function 

The CreateDibPalette() function that you just added to the application’s 
view class creates a logical palette from the currently loaded DIB’s color table. 
In that function, the program’s first task is to obtain a pointer to the CDib 
object’s color table. It does this by calling the CDib object’s 
GetDibRGBTablePtr() member function: 
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LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr () ; 


CreateDibPalette() also needs to know how many colors there are in the 
DIB’s color table. It gets this value by calling the CDib object’s 
GetDibNumColors() member function: 


UINT numColors = pDib->GetDibNumColors() ; 


Next, CreateDibPalette() defines a structure to hold the information Win- 
dows needs to create a logical palette: 


struct 


{ 
WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256]; 

} logicalPalette = { 0x300, 256 }; 


The preceding lines represent a LOGPALETTE structure, a data type defined by 
Windows and used when handling logical palettes. The first structure mem- 
ber is a version number, which should be the hex value 0x300. The second 
member is the number of colors in the palette. As you can see, 
CreateDibPalette() creates a 256-color logical palette. The final member is an 
array Of PALETTEENTRY structures. Windows defines the PALETTEENTRY structure 
as follows: 
typedef struct { 

BYTE peRed; 

BYTE peGreen; 

BYTE peBlue; 


BYTE peFlags; 
} PALETTEENTRY; 


The peRed, peGreen, and peBlue members of this structure hold the intensities 
of the color’s red, green, and blue components. The peFlags member specifies 
how Windows should handle the palette entry and can be the values 
PC_EXPLICIT, PC_NOCOLLAPSE, PC_RESERVED, or @. 


The PC_EXPLICIT flag indicates that the palette entry contains an index into 
the system palette, rather than actual color values. You store this index in the 
low-order word of the entry. You'll rarely need to use the PC_EXPLICIT flag. 


The PC_NOCOLLAPSE flag specifies that Windows should place the color into an 
empty system-palette entry, rather than map it to an existing entry. If there 
are no empty entries in the system palette, Windows overrides the 
PC_NOCOLLAPSE flag and performs normal matching instead. Other applica- 
tions may map their own colors to a palette entry marked PC_NOCOLLAPSE. 
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The PC_RESERVED flag prevents Windows from matching other applications’ 
colors to the color entry. You’d usually use the PC_RESERVED flag with ani- 
mated palettes, which frequently change color. Later, you’ll see how the 
PC_RESERVED flag can also make writing WinG applications easier. 


Set the peFlags member to @ when you want to let Windows handle the color 
entry any way it sees fit. 


Getting back to CreateDibPalette(), the function next copies the DIB’s color 
table into the logicalPalette structure and sets the peFlags member of each 
entry to 0: 


for(UINT i=@; i<numColors; ++i) 
{ 
logicalPalette.aEntries[i].peRed = 
pColorTable[i] .rgbRed; 
logicalPalette.aEntries[i].peGreen 
pColorTable[i].rgbGreen; 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i] .rgbBlue; 
logicalPalette.aEntries[i].peFlags 


Q; 

} 
Finally, CreateDibPalette() creates the logical palette by calling the Windows 
API function CreatePalette(), after which it returns a handle to the palette: 

hPalette = 

CreatePalette((LPLOGPALETTE) &logicalPalette) ; 

return hPalette; 
The Windows API function CreatePalette(), which returns a handle toa 
logical palette, takes as its single argument a pointer to a LOGPALETTE structure. 


Examining Changes to the OnDraw() Function 

In SHOWDIB’s OnDraw() function, you just added several lines of code that 
you may not understand. This section describes more fully what that new 
code accomplishes. 


The first line you added simply calls your new function, CreateDibPalette(), 
to create a logical palette from the DIB’s color table: 


HPALETTE hPalette = CreateDibPalette(pDib) ; 
The next line selects the newly created logical palette into the device context: 


HPALETTE hOldPalette = 
SelectPalette(pDC->m_hDC, hPalette, FALSE); 
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The Windows API function SelectPalette() selects a palette into a DC. Its 
three arguments are a handle to the DC, a handle to the palette, and a Bool- 
ean value indicating whether the palette is to always be a background palette 
(TRUE) or whether the palette should be a foreground palette when the Win- 
dow is active (FALSE). You’ll usually use FALSE for this argument. Note that 
SelectPalette() returns a handle to the old palette. You need to save this 
handle so that you can later remove the palette you created. 


Before you can use graphical objects (such as palettes, pens, and brushes) in a Win- 
dows program, the objects must be selected into (added to) the DC. 


Once OnDraw() selects the logical palette into the DC, it must realize the pal- 
ette, which tells Windows to map the palette to the system palette. The next 
line does this by calling the Windows API function RealizePalette(): 


RealizePalette(pDC->m_hDC) ; 


This function takes as its single argument the handle of the device context 
whose palette should be realized. 


After realizing the logical palette, OnDraw() displays the DIB, after which it 
deletes the logical palette. However, because an application must never delete 
an object that’s selected into a DC, OnDraw() must first remove the logical 
palette from the DC. It does this by selecting the old palette back into the 
DC: 


SelectPalette(pDC->m_hDC, hOldPalette, FALSE); 
Then, the program can safely delete the logical palette it created: 


DeleteObject(hPalette) ; 


Why delete a logical palette? Because, if you don’t delete graphical objects you 
create under Windows 3.1, they continue to take up memory after your application 
ends. if your application causes enough of this type of memory leak, you could pre- 
vent other applications from running correctly. However, although it’s always good 
practice to delete allocated objects, this hard-and-fast rule really applies only to 16- 
bit applications or 32-bit applications running under Win32s in Windows 3.1. Be- 
cause 32-bit applications running in Windows 95 or Windows NT have their own 
address spaces, undeleted objects don’t affect other applications in the system. 
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Running Version 2 of SHOWDIB 

The SHOWDIB application can now load and display a DIB, using the correct 
color palette. To use the program, select the File menu’s Open command and 
select a DIB file. SHOWDIB loads the selected DIB and displays it in its main 
window. Figure 2.24 shows the results when you select the DOGGIE2.BMP 
file, which is included with the WinG Developer’s Kit and is also found on 
this book’s CD-ROM, in the CHAPO2\SHOWDIB directory. As you see, 
SHOWDIB’s display looks much better when the program handles palettes 
correctly. 


showdib ; a ; 2 i $ = z i, 7 = j Z xj Fig. 2.24 
Zaan I AE Version 2 of 
SHOWDIB, with 
correct palette 
handling. 


Unfortunately, although SHOWDIB now displays DIBs properly when it’s the 
active application, it sometimes produces less than desirable results when it’s 
running in the background. For example, figure 2.25 shows SHOWDIB run- 
ning in the background while PC Paintbrush is running in the foreground 
with a different 256-color palette from the one SHOWDIB needs to display 
the DOGGIE2.BMP DIB properly. Ouch! 


Why isn’t SHOWDIB updating its display correctly? Shouldn’t Windows be 
mapping colors such that SHOWDIB produces a better-looking display than 
that shown in figure 2.25? The truth is that Windows is doing everything it 
can. The problem is SHOWDIB, which is not responding to Windows’ in- 
structions. Specifically, SHOWDIB is not responding to WM_QUERYNEWPALETTE 
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Fig. 2.25 

Version 2 of 
SHOWDIB 
running in the 
background 
without respond- 
ing to the WM_ 
PALETTECHANGED 
message. 


and WVM_PALETTECHANGED messages. You’ll learn about these messages as you 
create version 3 of the SHOWDIB application. 


Creating SHOWDIB, Version 3 


Version 2 of SHOWDIB enabled you to load a DIB and display it correctly. 
But, SHOWDIB does not yet behave correctly when it’s relegated to back- 
ground operation. Its display can become badly corrupted when the user 
activates another palette-managed application. Version 3 of SHOWDIB 
handles this problem by responding to two important Windows messages, 
WM_PALETTECHANGED and WM_QUERYNEWPALETTE. 


Responding to Palette Messages 

When the user activates an application, that application may realize its own 
logical palette. When this happens, the colors in the system palette may 
change significantly, leaving background applications looking strange. The 
solution to this problem is to notify background applications that the system 
palette has changed, which Windows does by sending a WM_PALETTECHANGED 
message. 


When a background application receives this message, it can realize its own 
logical palette, which tells Windows to remap the logical palette to the sys- 
tem palette. Because the active application has first claim on the colors in the 
system palette, background applications may lose some of their display integ- 
rity even when responding to WM_PALETTECHANGED, but at least Windows will 
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try for the best match possible between each background application’s logical 
palette and the new system palette. 


When a background application is reactivated, it can reclaim the system pal- 
ette. Windows notifies the application of this opportunity by sending a 
WM_QUERYNEWPALETTE message. The newly activated application responds to this 
message by realizing its logical palette, which forces all the logical palette’s 
colors into the system palette. At this point, the other running applications, 
which are now background applications, receive WM_PALETTECHANGED messages 
so that they can remap their logical palettes to the system palette, which you 
just changed. 


In the following section, you’ll learn how to modify a Visual C++ program in 
order to respond to the WM_PALETTECHANGED and WM_QUERYNEWPALETTE messages. 


Adding Code to SHOWDIB, Version 3 

To complete the SHOWDIB application, giving it the ability to update its 
display properly when it’s running in the background, follow the steps listed 
below. 


The complete source code and executable file for this final step in the creation of the 
SHOWDIB application can be found in the CHAPO2\SHOWDIB directory of this 
book’s CD-ROM. 


1. Select the Project menu’s ClassWizard command. When the MFC 
ClassWizard dialog box appears, select CMainFrame in the Class Name list 
box, as shown in figure 2.26. 


2. Select CMainFrame in the Object IDs list box, and then double-click the 
WM_PALETTECHANGED and WM_QUERYNEWPALETTE messages in the Messages list 
box. ClassWizard adds the OnPaletteChanged() and OnQueryNewPalette() 
member functions to the CMainFrame class. Click the OK button to final- 
ize your choices. 


3. Open the MAINFRM.CPP file, and find the new OnPaletteChanged() and 
OnQueryNewPalette() functions at the end of the file. 


4. Add the following code to the OnPaletteChanged() function, right after 
the // TODO: Add your message handler code here comment: 


// Get a pointer to the view window. 
CView* pView = GetActiveView() ; 
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// If it isn't the view window changing 

// the palette, redraw the view window with 

// the newly mapped palette. 

if (pFocusWnd != pView) 
pView->Invalidate() ; 


This code, which you’ll examine in detail later in this chapter, notifies 


the application’s view that it must realize the logical palette and redraw 
the display. 


Fig. 2.26 
Selecting the | 
CMainFrame class | 


; A CMainFrame ca 
in ClassWizard. i 
i OnCommand 
(TiD_APP_ABOUT |] OnCreateClient = 
ID_APP_ExIT |] OnFinaRelease  & 
ID_FILE_OPEN I] OnSetPreviewMode | 
PostNcDestr ‘ 
PreTranslateM 


W  OnPaletteChanged ON_WM_PALETTECHAN 
A OnQueryNewPalette ON_WM_QUERYNEWP, 


5. Add the following code to the OnQueryNewPalette() function, right after 
the // TODO: Add your message handler code here and/or call default 
comment: 


// Get a pointer to the view window. 
CView* pView = GetActiveView() ; 


// Redraw the view window with its own colors. 
pView->Invalidate() ; 
This code, which you'll examine in detail later in this chapter, notifies 
the application’s view that it must realize the logical palette and redraw 
the display. 


Version 3 of SHOWDIB is now complete. Before you run the application, 
however, read the following sections, which explain how the new code you 
added works. 
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Examining the OnPaletteChanged() Function 

The OnPaletteChanged() function is called whenever Windows sends the ap- 
plication a WM_PALETTECHANGED message, which it does whenever another ap- 
plication changes the system palette. When SHOWDIB receives this message, 
it must realize its palette and redraw its display. Because the view class is 
responsible for updating the display, OnPaletteChanged() must first acquire a 
pointer to the view: 


CView* pView = GetActiveView(); 


Next, the program must check whether it was its own view that modified the 
system palette. If it was, OnPaletteChanged() should ignore the 
WM_PALETTECHANGED message. Failure to handle the message in this way will 
leave your application in an infinite loop as it continually realizes its palette 
and then responds to the resulting WM_PALETTECHANGED message. Because the 
OnPaletteChanged() function receives as its single parameter a pointer to the 
window that changed the palette, you can compare this pointer with a 
pointer to your application’s view: 


if (pFocusWnd != pView) 


If the two pointers are not equal, some other application changed the palette. 
In this case, OnPaletteChanged() calls the view’s Invalidate() member func- 
tion, which forces a call to the view’s OnDraw() function: 


pView->Invalidate(); 


In OnDraw(), the program realizes its palette and draws the currently selected 
DIB. By realizing its palette in response to the WM_PALETTECHANGED message, the 
program’s logical palette is remapped to the newly changed system palette, 
creating the best possible display for this application as it’s running in the 
background. 


Examining the OnQueryNewPalette() Function 

The OnQueryNewPalette() function is called whenever Windows sends the 
application a WM_QUERYNEWPALETTE message, which it does whenever the appli- 
cation regains the focus (becomes the top window). Just as with the 
WM_PALETTECHANGED message, when SHOWDIB receives the WM_QUERYNEWPALETTE 
message, it must realize its palette and redraw its display. Because the view 
class is responsible for updating the display, OnQueryNewPalette() must first 
acquire a pointer to the view: 


CView* pView = GetActiveView(); 
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i 


OnQueryNewPalette() then calls the view’s Invalidate() member function, 
which forces a call to the view’s OnDraw() function: 


pView->Invalidate() ; 


In OnDraw(), the program realizes its palette and draws the currently selected 
DIB. By realizing its palette in response to the WM_QUERYNEWPALETTE message, 
the program’s logical palette is remapped to the system palette. Because 
SHOWDIB is, at this point, the active application, it can take over the system 
palette and create exactly the palette it needs. 


The Listings 


Following are the complete listings for the files in the SHOWDIB project that 
you modified over the course of this chapter. In these listings, code that you 
added manually is shown between double lines of slash characters. Code that 
you added using ClassWizard is listed normally—that is, it is not shown be- 
tween double lines of slash characters. Files that were created by AppWizard, 
but which you did not modify, are not shown here. If you’d like to know 
what the unlisted files contain, load them from disk using Visual C++ or 
some other text editor. 


Listing 2.3 MAINFRM.CPP—The Implementation File for the 


CMainFrame Class 


// mainfrm.cpp : implementation of the CMainFrame class 
// 


#include "stdafx.h" 
#include "“showdib.h" 


#include "mainfrm.h" 


#ifdef _DEBUG 

#undef THIS_FILE 

static char BASED CODE THIS_FILE[] = _ _FILE_ _; 
#endif 


FILLITTTTT TTT TTA AAA TAA AAA ATA AAT 
// CMainFrame 


IMPLEMENT_DYNCREATE(CMainFrame, CFrameWnd) 
BEGIN _MESSAGE_MAP(CMainFrame, CFrameWnd) 


//{{AFX_MSG_MAP (CMainFrame) 
ON_WM_PALETTECHANGED ( ) 
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ON_WM_QUERYNEWPALETTE ( ) 
/ 1 }}AFX_MSG_MAP 
END_MESSAGE_MAP() 


TELTLTTTTITT TTA TATA TATA AAT TTT ATTA ATT TTT 
// CMainFrame construction/destruction 


CMainFrame: :CMainFrame() 
// TODO: add member initialization code here 


} 


CMainFrame: :~CMainFrame() 
{ 
} 


PISILNI ATTA TAT AAA ATTA AAA AAA TA A 
// CMainFrame diagnostics 


#ifdef _DEBUG 
void CMainFrame: :AssertValid() const 


{ 
CFrameWnd: :AssertValid() ; 
} 
void CMainFrame: :Dump(CDumpContext& dc) const 
{ 
CFrameWnd: :Dump (dc); 
} 


#endif //_DEBUG 


TULTLTTTTT ATTA TATA ATTA TATA TATA AL 
// CMainFrame message handlers 


BOOL CMainFrame: :PreCreateWindow(CREATESTRUCT& cs) 

{ 
// TODO: Add your specialized code here and/or call the base 
// class 


TILTTTTTTTTT TTT TTT TTA AAA 
TITTTTTTTTTT TTT TTT ATT TTA AA TAT 
// START CUSTOM CODE 

[IIIIIIIII II IIIA IIIN 
SOLIA NIAIN ILALA ENA TIT AAPA E 


cS.CX 
cs.cy 


640; 
480; 


(continues) 
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Listing 2.3 Continued 


VILELE ELINAA AAL ATATIA TEADET 
FITTTLTTTTTTTT TTT TATA AAT ATLI 
// END CUSTOM CODE 

FITTTTTTTTTTT TTT TTA TAT ATTA TA A 
LILIECII ATES CE TTA TTT 


return CFrameWnd: :PreCreateWindow(cs) ; 
} 


void CMainFrame: :OnPaletteChanged(CWnd* pFocusWnd) 


{ 
CFrameWnd: :OnPaletteChanged (pFocusWnd) ; 


// TODO: Add your message handler code here 


LIATIN AAIE ATEOA TTET 
TTTTTITTTTTTTT TTT TTT TA TTT I 
// START CUSTOM CODE 

CESAS AALALA TAC ATCA TTT TTL 
VILVITE IAAI IAEN TILE A 


// Get a pointer to the view window. 
CView* pView = GetActiveView(); 


// If it isn't the view window changing 

// the palette, redraw the view window with 

// the newly mapped palette. 

if (pFocusWnd != pView) 
pView->Invalidate() ; 


TTITITTTTTTTTT TTT TTT ATTA TTA A 

[ILILILILIL TATA TL 

// END CUSTOM CODE 

COLETTE EAT AATETTA ECEE 

LOIALI L ANIA AAAA AN ATATA AE IT 
} 


BOOL CMainFrame: :OnQueryNewPalette() 


{ 
// TODO: Add your message handler code here and/or call default 


ALILIA TTT TTT TATA TTL 
[ILILILILIL TTT TAT TTT TATA TL 
// START CUSTOM CODE 

TITTTLTTTTTTTTTT ATTA TTT TTA TATA 
TITTTITTTTTTTT TTT TATA TTT ATA 


// Get a pointer to the view window. 
CView* pView = GetActiveView(); 


// Redraw the view window with its own colors. 
pView->Invalidate() ; 
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FITTLITTTTTTTT TTA TATA ATT TT TTT TT 
[IIIIIIIII II TTT TATA ATTA TL 
// END CUSTOM CODE 

TIITII TTT ATTA TATA TAA TT 
[IILIIIIII III ATT TATA AA ATT TT 


return CFrameWnd: :OnQueryNewPalette() ; 


eT 


Listing 2.4 SHOWDDOC.H—The Header File for the 


CShowdibDoc Class 


// showddoc.h : interface of the CShowdibDoc class 
// 
TPULLTTTUTT TTT TATA TAA AT ATA ATT TAT TL 


[ILIILIIIIII III IIA ITIITI 
FELTTTTTTTTTT TTT TT TATA TATA TL 
// START CUSTOM CODE 

[IIIIIIIL II III TTA TTT AAT AAT 
[IILI TTT TTT ATTA TTT AA ATT 


#include "“cdib.h" 


PLEIS TETIT INT EEATT EATE ALIA 
FILTTTTTTTLT TATA TTT TATA TATA ATT 
// END CUSTOM CODE 

[1111111111111111 TATA ATTA AAT 
TILAVA EIIN TTT ATTA AAT TT 


class CShowdibDoc : public CDocument 

{ 

protected: // create from serialization only 
CShowdibDoc() ; 
DECLARE_DYNCREATE (CShowdibDoc) 


// Attributes 
public: 


PEILI TELELANA IA AT AAT TTT 
/[II1II1IIIIIIII IILI 
// START CUSTOM CODE 

PILIL ATAATA TTT AAT ATA ATTA TTT 
LITTTTTTTT TTT TTT TATA TAT ATTA ATTA TTT 


CDib* m_pDib; 


[/IIIIIIIII III TTT AAT AAT TTT TT 
PICIS IAA EE CA ATA TTT 
// END CUSTOM CODE 

[I11111IIIII II IILI IILI 
[IIIIIIII III IIIT 


(continues) 
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Listing 2.4 Continued 


// Operations 
public: 


// Overrides 
// ClassWizard generated virtual function overrides 
//{{AFX_VIRTUAL (CShowdibDoc) 
public: 
virtual BOOL OnNewDocument() ; 
virtual void DeleteContents(); 
//}}AFX_VIRTUAL 


// Implementation 
public: 
virtual ~CShowdibDoc(); 
virtual void Serialize(CArchive& ar); // overridden for 
// document i/o 
#ifdef _DEBUG 
virtual void AssertValid() const; 
virtual void Dump(CDumpContext& dc) const; 
#endif 


protected: 


// Generated message map functions 

protected: 
//{{AFX_MSG(CShowdibDoc ) 
afx_msg void OnFileOpen() ; 
//}}AFX_MSG 
DECLARE_MESSAGE_MAP ( ) 

} 


FILTITTTTTTTTT TTT TTT TTT TTT TATA A 


Listing 2.5 SHOWDDOC.CPP—The Implementation File for the 
CShowdibDoc Class 


// showddoc.cpp : implementation of the CShowdibDoc class 
// 


#include "stdafx.h" 
#include "showdib.h" 


#include "showddoc.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED CODE THIS FILE[] = _ _FILE__; 
#endif 
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FILTLTTTTT TTT TATA TATA TT 
// CShowdibDoc 


IMPLEMENT_DYNCREATE(CShowdibDoc, CDocument) 


BEGIN_MESSAGE_MAP(CShowdibDoc, CDocument) 
//{{AFX_MSG_MAP (CShowdibDoc) 
ON_COMMAND(ID_FILE_OPEN, OnFileOpen) 
/ /}}AFX_MSG_MAP 

END_MESSAGE_MAP ( ) 


IIEL INATIA EILIA ATTA A I 
// CShowdibDoc construction/destruction 


CShowdibDoc: : CShowdibDoc() 


{ 
// TODO: add one-time construction code here 


FITTTTTTTTTT TTT TT TAT TTT TTT 
TALEC IATA ETITA TTT TTT TL 
// START CUSTOM CODE 

FITTITTTTTIT TTT TTT ATTA TTT 
FTTTTTTTTTTTTT TTT TTT TATA 


m_pDib = ð; 


FITITTTTTTTT TTT TT CEA EASA AAAA ANI 

FITTTTTTTTTT TTT TTT TATA TAT 

// END CUSTOM CODE 

TITTTTTTTTTT TTT TTT TATA TATA 

PITIE EA ALEEA TIITA TELEI 
} 


CShowdibDoc: :~CShowdibDoc() 
{ 
} 


BOOL CShowdibDoc: :OnNewDocument () 
{ 


if (!CDocument: :OnNewDocument() ) 
return FALSE; 


// TODO: add reinitialization code here 
// (SDI documents will reuse this document) 


return TRUE; 
} 


SAITI TATAI ATTA ATTA AAT 
// CShowdibDoc serialization 


(continues) 
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Listing 2.5 Continued 


void CShowdibDoc: :Serialize(CArchive& ar) 


{ 
if (ar.IsStoring() ) 
{ 
// TODO: add storing code here 
} 
else 
{ 
// TODO: add loading code here 
} 
} 


FULIIIIALLI TILATTU CA TATA TATA TTT T EI 
// CShowdibDoc diagnostics 


#ifdef _DEBUG 
void CShowdibDoc::AssertValid() const 


{ 
CDocument::AssertValid(); 
} 
void CShowdibDoc: :Dump(CDumpContext& dc) const 
{ 
CDocument: :Dump(dc) ; 
} 


#endif //_DEBUG 


PULTTTTTIL TTT TTT TTA TATA AAA TAT AAA TT 
// CShowdibDoc commands 


void CShowdibDoc: :OnFileOpen() 


{ 
// TODO: Add your command handler code here 


TITTITTTTTTT TTT ATTA TTA TAT TATA TAT 
AVIISI AINAANI A IATA 
// START CUSTOM CODE 

FTILTTTTTTTT TTT TTT TAT ATTA AAT TTL 
FITTTTTTTTTT TTT TTT TTT TAT ATTA ATT TTL 


// Construct an Open dialog-box object. 
CFileDialog fileDialog(TRUE, "bmp", "*.bmp"); 


// Display the Open dialog box. 
int result = fileDialog.DoModal() ; 


// If the user exited the dialog box 

// via the OK button... 

if (result == IDOK) 

{ 
// Get the selected path and file name. 
CString string = fileDialog.GetPathName() ; 


// Construct a new CDib object. 
m_pDib = new CDib(string) ; 


// Check that the CDib object was created okay. 
// If there was an error, the pBmInfo pointer 


// will be ðQ. 


LPBITMAPINFO pBmInfo = m_pDib->GetDibInfoPtr(); 


// If the CDib object was not constructed 


// properly, delete it. 
if (!pBmInfo) 
DeleteContents() ; 


// Otherwise, set the document's title to 


// the DIB's path and file name. 
else 
SetTitle(string) ; 
} 


// Notify the view object that it has new data to display. 


UpdateAllViews (0) ; 


LAINAA AATTEITA 

FITLTITTTTTTTT TT TTT ETAIT AA 

// END CUSTOM CODE 

IALIA ETAC ATELLA UELLE 

[ILILILILIL 
} 


void CShowdibDoc: :DeleteContents() 
{ 


// TODO: Add your specialized code here and/or call the base 


// class 


TLTTTTTTTTTTT TTT TTT TTT AT TT 
TITTTTTTTTTTTT TTT TTT TATA TATA TTT TL 
// START CUSTOM CODE 

TLITTTTTTTTTT TTT TATA TA 
FITTTTTTTTTTTTTATT TATA TTT 


// If there's a valid CDib object, delete it. 


if (m_pDib) 

{ 
delete m_pDib; 
m_pDib = 0; 

} 


[ILILILILIL 
[ILILILILIL 
// END CUSTOM CODE 

FITITTTTTATTTTT TTT TTT TAT 
[ILILILILIL 


CDocument::DeleteContents(); 
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Listing 2.6 SHOWDVW.H—The Header File for the 


CShowdibView Class 


// showdvw.h : interface of the CShowdibView class 
// 
TIIAILITITAIALITAIIAN LALIT AAA AAA AA AT AAT 


class CShowdibView : public CView 


protected: // create from serialization only 
CShowdibView() ; 
DECLARE_DYNCREATE (CShowdibView) 


// Attributes 
public: 
CShowdibDoc* GetDocument() ; 


// Operations 
public: 


// Overrides 
// ClassWizard generated virtual function overrides 
//{{AFX_VIRTUAL (CShowdibView) 
public: 
virtual void OnDraw(CDC* pDC); // overridden to draw this view 
protected: 
/ /}}AFX_VIRTUAL 


// Implementation 
public: 
virtual ~CShowdibView() ; 
#ifdef _DEBUG 
virtual void AssertValid() const; 
virtual void Dump(CDumpContext& dc) const; 
#endif 


protected: 


PIITAN TTT TTT TTT TATA ATL 
[/IIILIII III TTT TTT TATA AL 
// START CUSTOM CODE 

TITTTTTTTTTTTT TTT TTT TTT TAA TTT 
[IILL III TTT TTT TATA TTA TAL 


HPALETTE CreateDibPalette(CDib* pDib) ; 


FELTTTTTTTTTT TTT TT ATTA TATA 
LLLITITTTTTTT TTT TATA TATA ATA 
// END CUSTOM CODE 

TILITTTTTTTTT TTT TAT TATA AAA ATT 
FILITLTTTTTTT TTT TTT TTT TATA AA TATA TD 


// Generated message map functions 
protected: 
//{{AFX_MSG (CShowdibView) 


The Listings 73 


// NOTE - the ClassWizard will add and remove member 
// functions here. 
// DO NOT EDIT what you see in these blocks of generated 
// code! 
//}}AFX_MSG 
DECLARE_MESSAGE_MAP (( ) 


}; 


#ifndef _DEBUG // debug version in showdvw.cpp 

inline CShowdibDoc* CShowdibView: :GetDocument () 
{ return (CShowdibDoc*)m_pDocument; } 

#endif 


CIECA ACILIA ELLA ATIII IEAA AAA 
aaa 


Listing 2.7 SHOWDVW.CPP—The Implementation File for the 


CShowdib View Class 


// showdvw.cpp : implementation of the CShowdibView class 
// 


#include "stdafx.h" 
#include "“showdib.h" 


#include "“showddoc.h" 
#include "showdvw.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED_CODE THIS FILE[] = _ _FILE__; 
#endif 


TLTTLTTTTTTTTT TTT TTT TAT TTT TTA AT 
// CShowdibView 


IMPLEMENT_DYNCREATE(CShowdibView, CView) 


BEGIN _MESSAGE_MAP(CShowdibView, CView) 
//{{AFX_MSG_MAP (CShowdibView) 
// NOTE - the ClassWizard will add and remove mapping 
// macros here. 
// DO NOT EDIT what you see in these blocks of generated 
// code! 
//}}AFX_MSG_MAP 
END_MESSAGE_MAP( ) 


PLTA ANAAL TTT TTT ATTA TATA AAT AA TATA AAA AA 
// CShowdibView construction/destruction 


(continues) 
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Listing 2.7 Continued 


CShowdibView: : CShowdibView( ) 


// TODO: add construction code here 


} 


CShowdibView: :~CShowdibView( ) 
{ 
} 


PETTITT TTTT TTT ATA AAA AAA TAT TATA TATA TAA AD 
// CShowdibView drawing 


void CShowdibView: :OnDraw(CDC* pDC) 

{ 
CShowdibDoc* pDoc = GetDocument() ; 
ASSERT_VALID(pDoc) ; 


// TODO: add draw code for native data here 


[IIIIIIIIIIIII TTT TTT AAT TTA TTT 
FITTLLTTTTAT TTT TTT TTT AAT AA TA TT 
// START CUSTOM CODE 

FLLTITTTTTTT TATA TATA ATTA ATTA TAT 
PILITIN AAAA TTT TTA TATA AAT ATA 


// Get a pointer to the current CDib object. 
CDib* pDib = pDoc->m_pDib; 


// If the CDib object is valid, display it. 
if (pDib) 
{ 
// Create the DIB's palette; 
HPALETTE hPalette = CreateDibPalette(pDib) ; 


// Select the DIB's palette into the DC. 
HPALETTE hOldPalette = 
SelectPalette(pDC->m_hDC, hPalette, FALSE); 


// Map the DIB's palette to the system palette. 
RealizePalette(pDC->m_hDC) ; 


// Get a pointer to the DIB's image data. 
BYTE* pBmBits = pDib->GetDibBitsPtr(); 


// Get a pointer to the DIB's info structure. 
LPBITMAPINFO pBmInfo = pDib->GetDibInfoPtr() ; 


// Get the DIB's width and height. 
UINT bmWidth = pDib->GetDibWidth() ; 
UINT bmHeight = pDib->GetDibHeight() ; 
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// Display the DIB. 
StretchDIBits(pDC->m_hDC, 

10, 10, bmWidth, bmHeight, 

©, ®, bmWidth, bmHeight, 

pBmBits, pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


// Deselect the logical palette from the DC. 
SelectPalette(pDC->m_hDC, hOldPalette, FALSE); 


// Delete the logical palette. 
DeleteObject(hPalette) ; 
} 


FTTTTTTTTTTT TTT TTT TTT TTT AAA 

[IIIT II IIIA 

// END CUSTOM CODE 

TAI IITI TAIAT ITACA TEITEI EEA 

FTLTTTTTTTTTT TTT TATA 
} 


VIITA EIEII CLA NLININE EIA TTT AAA AAA A AL 
// CShowdibView diagnostics 


#ifdef _DEBUG 
void CShowdibView: :AssertValid() const 


{ 
CView: :AssertValid(); 
} 
void CShowdibView: :Dump(CDumpContext& dc) const 
{ 
CView: :Dump(dc) ; 
} 
CShowdibDoc* CShowdibView: :GetDocument() // non-debug version is 
// inline 
ASSERT (m_pDocument ->IsKindOf (RUNTIME_CLASS(CShowdibDoc) )) ; 
return (CShowdibDoc*)m_pDocument ; 
} 


#endif //_DEBUG 


[ILILILILIL 
// CShowdibView message handlers 


[ILILILILIL 
[IIIIIIII ITIITI 
// START CUSTOM CODE 

CAINTA EIL TATAEE UI 
FILTTTTTTTTTTTT TTT ATTA TATA ATT TTT 


HPALETTE CShowdibView: :CreateDibPalette(CDib* pDib) 
{ 


(continues) 
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Listing 2.7 Continued 


// Get a pointer to the DIB's color table. 
LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr() ; 


// Get the number of colors in the DIB. 
UINT numColors = pDib->GetDibNumColors() ; 


struct 

{ 
WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256] ; 

} logicalPalette = { 0x300, 256 }; 


// Fill the palette structure with the DIB's colors. 
for(UINT i=@; i<numColors; ++i) 
{ 
logicalPalette.aEntries[i].peRed = 
pColorTable[i].rgbRed; 
logicalPalette.aEntries[i].peGreen = 
pColorTable[i].rgbGreen; 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i] .rgbBlue; 
logicalPalette.aEntries[i].peFlags = 0; 
} 


// Create the palette object. 
HPALETTE hPalette = 
CreatePalette((LPLOGPALETTE) &logicalPalette) ; 


return hPalette; 
} 


[ILILILILIL 
[ILILILILIL IIIA 
// END CUSTOM CODE 

[ILILILILIL 
[ILILILILIL AAA TAT AL 


Summary 


Loading a device-independent bitmap (DIB) can be a tricky proposition. To 
handle these graphical objects, you must first know about the 
BITMAPFILEHEADER, BITMAPINFO, BITMAPINFOHEADER, and RGBQUAD data structures. 
In addition, you must know how to reserve memory for a DIB, how to load 
the DIB’s data into that reserved memory, and how to display the DIB by 
calling the Windows API function StretchDIBits(). 


Summary 


Getting the DIB loaded and displayed, however, is only half the battle. You 
must also create a logical palette from the DIB’s color table and realize that 
palette, so that its colors can be mapped into the system palette. Handling 
logical palettes also requires that your program respond to the 
WM_PALETTECHANGED and WM_QUERYNEWPALETTE Windows messages. 


Now that you know how to properly load and display DIBs, you’re ready 
to start learning about WinG, which uses DIBs extensively in game 
programming. 
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Why WinG? 


There are several operating systems available for owners of PC-compatible 
computers, but few people would argue against the fact that Microsoft Win- 
dows has dominated the market. All the best applications are available for 
Windows, and just about every new computer comes with Windows already 
installed. When you consider the immense popularity of Windows, you 
might begin to wonder why there are so few games available for this OS 
leader. 


If you’ve ever programmed under Windows, you already know why all the 
best games still run only under good, old, clunky DOS. It’s because Windows 
is so gosh-darn slow at doing exactly the sort of things that games need to do 
the fastest. Ironically, Windows, which is a graphical user interface that relies 
on tons of cute little icons and buttons, is slowest at handling graphics. And 
any operating system that can’t handle graphics at blazing speeds can’t 
handle games—at least not games that require transferring a lot of graphics 
between memory and the screen. 


So why is DOS so much better at handling graphics than Windows? It’s be- 
cause DOS lets you dig in deep, creating your own custom graphics routines 
and accessing graphics directly in memory. Windows, on the other hand, in 
its attempt to provide a device-independent environment, requires that all 
graphics handling go through its GDI (Graphics Device Interface), which is a 
library of handy, but generally slow, graphics functions for doing such things 
as drawing lines and transferring bitmaps to the screen. Because of the GDI, 
games that require high-powered graphics engines were impossible to write 
for Windows...until WinG came along, that is. 
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Why Game Programmers Need Fast 
Graphics 


But before you start learning about WinG, you need to understand why fast 
graphics are so important in games. The truth is that, in most games, the 
slowest code is the code that moves around graphics data. One reason for 
this is that today’s computers can handle very detailed images. Such high- 
resolution images require huge amounts of memory. 


Take, for example, a 256-color image with a resolution of 640 x 480. A 640 x 
480 screen is made up of 307,200 individual dots of color (called pixels). Each 
of those dots must be represented by eight bits in memory, because eight bits 
are required to allow for 256 different color combinations. (This is why 256- 
color pictures are often referred to as 8-bit images.) Therefore, storing a 640 x 
480, 256-color image in memory requires 307,200 bytes. That’s a third of a 
megabyte! In order to display that image on the screen, the program must 
transfer the image in RAM to the screen’s memory. 


Now, imagine that you’re using this 256-color image as the background scene 
in a game. Because the background scene is constantly changing (maybe the 
game is a flight simulator), your program must repeatedly transfer a new 
image to the screen. Fifteen images a second wouldn’t be unusual (it would, 
in fact, be a fairly slow screen update). So, now the program has to move 15 x 
307,200 bytes—almost five megabytes—of graphical data each second. Things 
are really starting to slow down now. 


But there’s still more. Suppose in this game there are objects that move 
around on top of this constantly changing scene. These objects (called sprites 
in computer-gaming lingo) include the player’s on-screen character, as well as 
all the enemies the player is currently fighting. Sprites are graphical objects 
that must be transferred to the screen, too. So, now the program must not 
only transfer the background scene to the screen 15 times a second, but it 
must also transfer each sprite, one by one, onto this image. 


This scenario ignores the problems one encounters when trying to animate 
sprites directly on the screen. Because simple animation produces an annoy- 
ing flicker as sprites constantly appear and disappear, game programmers 
usually compose a complete scene in memory before transferring that scene 
to the screen. This virtually doubles the amount of graphical data that must 
be transferred, because now the new background scene must be transferred 
from one part of memory to another, the sprites are added, and then the 
whole thing is transferred to the screen. When you think about it, it’s a 
miracle computer games work at all! 


WinG’s Two Great Talents 


Enter WinG 


Without some help, Windows 3.1 is so slow that handling graphics as de- 
scribed in the preceding section is as tough and as slow as building a battle- 
ship of toothpicks. In short, it’s just plain impossible. This is where WinG 
comes in. 


WinG is nothing more than an extension graphics library for handling 
bitmaps under Windows. If you’ve looked at WinG’s programmer’s reference, 
you may be a little surprised that WinG comprises less than a dozen func- 
tions, many of which you don’t even need in most programs. WinG isn’t big 
because it doesn’t attempt to replace the whole GDI with faster routines. 
What it does is give you the necessary tools to transfer bitmaps quickly be- 
tween memory and the screen. Much beyond that, just like DOS, it’s up to 
you to supply your own graphics tools. 


For example, suppose you want to draw a picture in memory that’s made up 
of hundreds of lines. Such a picture would take forever (at least in terms of 
computer speed) to draw with the GDI. But, because you can’t directly access 
bitmaps under Windows, you would have no choice but to use the GDI’s 
slow line-drawing function. 


So, you use WinG, instead, and write your own line-drawing function. This 
function could even be in assembly language for super speed. You can use 
such a custom graphics routine because WinG gives you direct access to 
bitmaps in memory, something Windows strictly forbids. Just as DOS game 
programmers can draw directly on surfaces they’ve stored in memory, so too 
can WinG programmers. Voila! Action games under Windows suddenly be- 
come a possibility. 


WinG’s Two Great Talents 


Although the WinG library offers a few extra goodies for graphics program- 
mers, when you come right down to it, WinG boasts two important abilities 
that help you develop games for Windows: 


1. Direct access to bitmaps in memory 


2. A fast way to transfer bitmaps from memory to the screen 


These two simple extensions to Windows’ graphics abilities are really all you 
need (besides any custom routines you may want) to write zippy games for 
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Windows. In fact, thanks to WinG, there is currently even a version of Doom 
for Windows that’s reputed to sizzle almost as much as the DOS version does. 


Windows 3.x, Windows NT 3.x, or 
Windows 95? 


You may wonder, at this point, exactly which incarnation of Windows I’ve 
been referring to. The truth is that, currently, WinG is designed mostly for 
programmers who want to write zippier games for Windows 3.1. Windows 
NT and Windows 95 already have graphics abilities similar to WinG’s built 
right in. “Hey,” you say, “I bought this book to learn about programming 
32-bit games! What’s Windows 3.1 got to do with anything?” 


A good question, which luckily for me has a good answer. It’s going to be 
quite a while before Windows 95 (or NT) gets a solid hold on the computer 
industry. In the meantime, most Windows users will continue to chug along 
with Windows 3.1. Wouldn’t you like to program 32-bit games that run 
under all three incarnations of Windows? That way, you won’t limit your 
potential customers to the few brave souls who spring immediately for 
Windows 95. 


Using WinG, you can write 32-bit games that run well on all Windows ma- 
chines. The only caveat is that, when running under Windows 3.x, such 
games require that Win32s, a subset of the Win32 system, be installed on 
the user’s machine. Win32s allows most 32-bit programs to run on the 
16-bit Windows 3.x, with only about a 10 to 15 percent degradation in 
performance. 


So, although WinG is not required for writing high-powered games for Win- 
dows NT or Windows 95, it does work well under both of those environ- 
ments. WinG is smart enough to use its own routines when running under 
Windows 3.1 and to use the Win32 API when running under Windows NT 
or Windows 95. 


Another reason for using WinG for 32-bit Windows games is that, according 
to Microsoft, any future graphical enhancements for 32-bit Windows envi- 
ronments will be added to WinG, rather than to the Win32 API. This means, 
of course, that if you want to be sure that your programs can easily take ad- 
vantage of such enhancements, you ought to use WinG for programming 
games under any Windows environment. (Microsoft hasn’t promised any 
enhancements; they’ve only said that, if they were to make enhancements, 
they’d place them in WinG.) 
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If you want to avoid using WinG on Windows NT or Windows 95, you can 
create directly accessible bitmaps with the CreateDIBSection() function. Be- 
cause the 32-bit Windows environments are already optimized for graphics, 
you can use Windows functions to transfer bitmaps between memory and the 
screen. But, because WinG automatically drops through to the Win32 API 
when you run it in a 32-bit environment, and does it with no discernible 
decrease in performance, why not use WinG for your games and be set up to 
take advantage of any future enhancements Microsoft might add? 


Installing WinG 


Now that you have some idea of what WinG is and why you should use it, 
it’s time to install the WinG developer’s kit and the WinG sample applica- 
tions on your system. To do this, follow these steps: 


1. 


Copy the WINGINST directory and all its contents from this book’s 
CD-ROM to your hard drive. 


From Windows’ Start menu, select the Run command. You see the Run 
Application dialog box, as shown in figure 3.1. 


Fig. 3.1 
The Run Applica- 
tion dialog box. 


In the Open edit box, type C:\WINGINST\SETUP. You see the 
Microsoft Setup window, as shown in figure 3.2. 


Click the Continue button to begin installing WinG. The WinG Setup 
Options dialog box appears, as shown in figure 3.3. 


Make sure both options are checked, and then click the Continue but- 
ton. The Setup program copies a couple of files, and then asks for the 
name of the directory where you'd like the WinG files stored (see 

fig. 3.4). 


Leave the directory name unchanged, and click the Continue button. 
The setup program installs WinG, after which you see the WinG SDK 
group appear on-screen (see fig. 3.5). 
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Fig. 3.2 
The Microsoft 
Setup window. 


Fig. 3.3 

The WinG Setup 
Options dialog 
box. 


Fig. 3.4 

The WinG setup 
program asks for a 
directory. 


| Micresoft Setup 


Welcome to the Microsoft WinG Setup. 


Use this program to install the WinG 
runtime libraries. as well as sample code. 
documentation, import libraries and include 
files for creating WinG applications. 


A I Install WinG Runtime Libraries 
M Install WinG Development Kit 


The setup program will install the WinG 
development directory tree structure using 
this base directory: 


Path: [C:\WING 


Please make sure that the filepaths to the 
WinG INCLUDE and LIB sub-directories are 
added to the respective INCLUDE and LIB 
environment variables. 


As you can see, the WinG SDK group contains several sample programs that 
demonstrate many of WinG’s talents. The setup program has installed these 
programs, including full source code, in the WING\SAMPLES directory on 
your hard disk. Your WinG directory also contains the other files that must 
be installed on a system so that WinG applications can run. These files 
include WING.DLL, WING32.DLL, WINGDE.DLL, WINGDIB.DRV, and 
WINGPAL.WND. 


Another important file is WING.H, which you can find in the 


[f WinG SDK 


a+ hs 


Halftone 


Palette Time WinG = — WinG Bug 
Animation Reporting Tool 
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Fig. 3.5 
The WinG SDK 


group. 


WING\INCLUDE directory. This header file declares the WinG functions and 
must be included in source code files that call these functions. Finally, WinG 


includes a Help file that offers sample source code, as well as helpful pro- 
gramming techniques for creating WinG applications. This file is located in 
the WING\HELP directory. Just double-click WING.HLP to load it into Win- 


dows’ Help system. You’ll then be able to browse easily through the informa- 
tion provided in the Help file (see fig. 3.6). 


2 WinG Programmer's Reference 


Off-screen Drawing With WinG 


WinG introduces a new type of device context, the WinGDC, that can be used like any other device 
context. Unlike other DCs, programmers can retrieve a pointer directly to the WinGDC drawing 


surfaces for the WinGDC or modify the color table of an existing surface. DIBs become as easy to 
use as device-specific bitmaps and compatible DCs, and programmers can also draw into them using 


their own routines. 


Most often, applications will use WinGCreateDC to create a single WinGDC and will use 
WinGCreateBitmap to create one or more WinGBitmaps into which they compose an image. The 
application will typically draw into this buffer using DIB copy operations, GDI calls, WinG calls, and 


custom drawing routines, as shown here. 


GDI Drawing 


Routines Routines 


Custom Drawing 


Fig. 3.6 
Browsing WinG’s 
Help file. 
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Running WinG Applications under 
Windows 3.1 


As you learned previously, WinG is most effective when used for programs 
that will run under Windows 3.1. To get the most out of your hardware, 
WinG does more than just provide fast graphics routines. It also analyzes 
your hardware to determine the absolute best way to do things on your spe- 
cific system. 


The first time you run a WinG program under Windows 3.1, a configuration 
program springs into action and starts checking out your hardware. As you 
watch, the program moves image data between memory and the screen, mea- 
suring the speeds at which the different transfers work. This process usually 
takes a couple of minutes, but must be done only the first time you use a 
WinG program. When the test program has completed analyzing your sys- 
tem, the WinG program you wanted to start appears on-screen. 


Running WinG Applications under 
Windows NT or Windows 95 


Because Windows NT and Windows 95 are already optimized for fast graphics 
performance, the WinG test program does not run the first time you start a 
WinG application under these operating systems. Instead, the application 
starts immediately. 


Doggie: The Prototype WinG 
Application 


By now, you’te probably dying to try out a WinG program. That’s exactly 
what you’ll do here. Despite its silly name, the DOGGIE sample program does 
just about everything a WinG program needs to do to achieve maximum 
performance under Windows. 


When you first run the DOGGIE program, you see the window shown in 
figure 3.7. This window contains nothing more than a bitmap of what ap- 
pears to be a balloon dog. 


Not too impressive, yet (except for the cool artwork). The magic happens 
when you use your mouse to drag the bitmap around the screen. When you 
do, the bitmap is redrawn in each new position almost as fast as you can 
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move the mouse (see fig. 3.8). You can’t get this kind of graphics speed under 
Windows 3.1 without WinG! 


WinG Sprite Demo . | Fig. 3.7 
: : The DOGGIE 
sample program. 


Fig. 3.8 
Dragging the 
doggie around 
the screen. 


Doggie: WinG Sprite Demo 


The other sample programs display more of WinG’s strengths, including 
halftoning to simulate more than 256 colors (HALFTONE, shown in fig. 3.9), 
displaying 24-bit bitmaps using dithering (CUBE, shown in fig. 3.10), and 
palette animation (PALANIM). There’s also a timing application (TIMEWING) 
that compares conventional Windows bitmap transfers to WinG’s more 
speedy ones (see fig. 3.11). 
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Fig. 3.9 inG Halftoning Sample Ee 
The HALFTONE | File Dither 
sample program. 


Fig. 3.10 Spinning Cube 

The CUBE sample Bile _Dither 

program. 

Fig. 3.11 JWING\SAMPLES\TIMEWING\FROG.BMP - 266 x 211 [=a 


The TIMEWING Stretch Time All Time 
sample program. 


StretchBit: 59.31 per Second 
StretchDIBits: 30.42 per Second 
WinGStretchBit top-down: 69.35 per Second 
WinGStretchBit bottom-up: 69.40 per Second 


Digging into WinG 


All of the preceding sample program screens were captured under Windows 
3.1, where WinG has the greatest effect. If you look at the timing program 
shown in figure 3.11, you can see exactly how much of an effect WinG really 
does have. The functions you should compare are WinGStretchBit() and 
StretchDIBits(), because the first is WinG’s DIB-transfer function and the 
second is the GDI’s DIB-transfer function. (StretchB1t() works only with 
device-dependent bitmaps, rather than device-independent bitmaps.) 
WinGStretchB1t() is more than twice as fast as StretchDIBits() on this ma- 
chine, drawing 69 bitmaps per second to the latter’s 30. 


Digging into WinG 


As I mentioned before, WinG provides a library of functions for handling 
bitmaps under Windows and for dealing with a few other graphical chores. 
Before you move on to the next chapter and get to programming, you might 
want to take a quick look at what WinG’s function library includes. The 
WinG functions are listed in table 3.1. 


Table 3.1 WinG Functions 


Function Description 

WinGBitBlt() Rapidly transfers a bitmap from memory to the 
screen. 

WinGCreateBitmap() Creates a bitmap compatible with a WinG 
device context. 

WinGCreateDC() Creates a WinG device context. 

WinGCreateHalftoneBrush() Creates a dithered brush that simulates a 24-bit 
color brush. 

WinGGetDIBColorTable() Returns the color table of the bitmap currently 
attached to a WinG device context. 

WinGGetDIBPointer () Returns a pointer to the image data of the 
bitmap currently attached to a WinG device 
context. 

WinGRecommendDIBFormat ( ) Initializes a BITMAPINFO structure with values 


that should be used to create a bitmap for a 
WinG device context. 


WinGSetDIBColorTable() Changes the color table of the bitmap currently 
attached to a WinG device context. 


(continues) 
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Table 3.1 Continued 


Function Description 


WinGStretchB1t () Copies and scales a bitmap from a WinG device 
context to the screen. 


The most useful functions—and those on which you’ll concentrate in this 
book—are WinGBitB1t(), WinGCreateBitmap(), WinGCreateDC(), and 
WinGRecommendDIBFormat(). The other functions are useful in specific circum- 
stances, but the aforementioned functions can be found in every WinG pro- 
gram. They are the functions that make hot games under Windows possible. 


Summary 


Due to its generally slow speed, Windows has never been a good platform for 
computer games. This is because handling graphics under Windows is way 
too slow to allow quick transfer of graphical data between memory and the 
screen. 


However, WinG, which is a library of graphics functions that address the 
speed issues associated with graphics under Windows, provides very fast 
bitmap transfer functions. WinG also gives a programmer direct access to a 
bitmap’s image in memory. This direct bitmap access allows a programmer to 
write custom graphics routines, instead of having to rely on Windows’ slow 
GDI functions. 


Although WinG is designed mostly to help programmers create games for 
Windows 3.1, it also works fine under Windows NT and Windows 95, auto- 
matically taking advantage of those operating systems’ built-in, optimized 
graphics functions. In addition, because Microsoft will apply all future 
graphical enhancements to WinG, programmers who use WinG in these 32- 
bit environments will enjoy access to these possible future enhancements. 


In the next chapter, you really start to see what WinG is all about as you 
program your first WinG applications. 


Chapter 4 
Programming with 
WinG 


Now that you’ve had an introduction to WinG and have some idea of what it 
does, it’s time to use WinG in an actual program. Then, you'll not only get 
hands-on experience with the WinG API, but you'll also be able to see it in 
action, which will go a long way toward dispelling any mystery that remains. 


As you learn more about WinG, keep in mind that its main purpose is to 
provide a directly accessible drawing surface in memory, as well as the ability 
to transfer that drawing surface quickly to the screen. This process is impor- 
tant for game programmers, because they frequently need to update the 
screen as often as 30 times a second. For this reason, many Windows game 
programs require not only functions like WinGBitB1t(), which transfer the 
WinG bitmap to the screen, but also custom drawing routines that can com- 
pose an image on that bitmap as quickly as possible. 


There are several programming steps required to take advantage of WinG ina 
Windows program. You should keep the following steps in mind as you de- 
velop the WinG application that follows: 


1. Call WinGRecommendDibFormat() to discover whether your WinG bitmap 
should be stored top-down or bottom-up in memory. 


2. Create a BITMAPINFO structure for the WinG bitmap. 
3. Create an identity palette. 
4. Call WinGCreateDC() to create a WinG device context. 


5. Call WinGCreateBitmap() to create a WinG bitmap that’s compatible 
with the WinG DC. 
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6. Select the WinG bitmap into the WinG DC. 


7. Draw an image on the WinG bitmap, usually using custom drawing 
routines for speed. 


8. Select the identity palette into the application window’s DC. 


9. Transfer the WinG bitmap to the screen by calling winGBitBl1t(). 


These steps may seem like a lot of work, and no doubt much of this informa- 
tion is still confusing to you. But fear not. All will be explained in the pages 
that follow. Once you get the hang of using WinG, you'll discover that many 
of the steps in this list are little more than program overhead—something 
you do once when your program starts up. 


Creating WINGEX, Version 1 


To keep things as understandable as possible, you’ll build your first WinG 
program a step at a time. In each version of the program that follows, you’ll 
add another critical piece to the puzzle, until you finally have a simple WinG 
program, complete with animation. In this section, you create the basic 
AppWizard application on which the final WinG program is based. 


The complete source code and executable file for this step in the creation of the 
WINGEX application can be found in the CHAPO4\WINGEX1 directory of this book’s 
CD-ROM. 


1. Use AppWizard to create the basic files for the WINGEX program, se- 
lecting the options listed in the following table. When you’re done, 
the New Project Information dialog box appears; it should look like 
figure 4.1. 


TN 
Dialog Box Name Options to Select 


New Project Name the project WINGEX and set the project path to 
C:\MSVC20. Leave the other options set to their defaults. 

Step 1 Select Single Document. 

Step 2 of 6 Leave set to defaults. 


Step 3 of 6 Leave set to defaults. 
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Dialog Box Name Options to Select 
Step 4 of 6 Turn off all application features except Use 3D Controls. 


Step 5 of 6 Leave set to defaults. 


Step 6 of 6 Leave set to defaults. 


[New Project Information Bee ia Ea Fig. 4.1 

Application 

: : options for the 
Singe e Document Interface Application targeting: basic WINGEX 

program. 


Classes to be created: 
Application: CwWingexApp in wingex.h and wingex.cpp 
Frame: CMainFrame in mainfrm.h and mainffm.cpp 
Document CWingexDoc in wingedoc.h and wingedoc.cpp 
View: CWingexView in wingevw.h and wingeyw.cpp 


Features: 
+MSVC Compatible project file (wingex.mak) 
+ 3D Controls 
+ Uses shared DLL implementation (MFC30.DLL) 
+ Localizable text in U.S. English 


2. Double-click the WINGEX.RC file in the project window. The resource 
browser window appears, as shown in figure 4.2. 


Fig. 4.2 

The WINGEX 
project’s resource 
browser window. 


3. Double-click the Menu resource, and then double-click the 
IDR_MAINFRAME resource ID. The menu editor appears, as shown 
in figure 4.3. 


4. Click on the Edit menu in the editor, and press your keyboard’s Delete 
key to delete the menu. 


5. Click on the File menu in the editor, and then use your keyboard’s 
arrow and Delete keys to delete all commands in the menu except Exit. 
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Fig. 4.3 

The WINGEX 
project’s menu 
editor. 


Fig. 4.4 
Editing WINGEX’s 
About dialog box. 


wingex.re - | 


From now on in this book, the details for modifying menu resources will be 
much briefer. If you have trouble with them, refer to this list. 


Close the menu editor window and double-click the Accelerator re- 
source in the resource browser. Click on the IDR_MAINFRAME ID and press 
your keyboard’s Delete key to delete the accelerators. 


Double-click the Dialog resource in the resource browser, and then 
double-click the IDD_ABOUTBOx resource ID. The dialog editor appears. 


Modify the dialog box by adding the static string "by Macmillan 
Computer Publishing", as shown in figure 4.4. 


x (Dialog) 


From now on in this book, the details for modifying dialog boxes will be much 
briefer. If you have trouble with them, refer here. 


Close the dialog box editor and the resource browser, making sure you 
save the changes when asked. 
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Running WINGEX, Version 1 

You’ve now created the basic WINGEX application, as well as modified its 
user interface. To compile the program, select the Project menu’s Rebuild All 
command. Visual C++ then compiles and links the application. When it’s 
finished, you can run WINGEX by selecting the Project menu’s Execute com- 
mand. When you do, you see the window shown in figure 4.5. 


Fig. 4.5 
WINGEX, 
version 1. 
In its current version, WINGEX can perform only two operations. If you click 
on the Help menu’s About Wingex command, you see the program’s About 
dialog box (see fig. 4.6). The only other command that the program handles 
is the File menu’s Exit command. When you select this command, the pro- 
gram terminates (of course). 
Unt oR GEN ane EE Ai Fig. 4.6 
Le n = Displaying 


WINGEX’s About 
dialog box from 


eee ee Version 1.0 the Help menu. 
AFK Copyright © 1995 
by Macmillan Computer Publishing 
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Creating WINGEX, Version 2 


Every WinG program must create a WinG device context (DC) and attach a 
WinG bitmap to that DC. Because these are the basic tasks that all WinG 
programs must complete, and because those tasks are not quite as simple as 
they may sound at first, version 2 of WINGEX is dedicated to these important 
WinG programming techniques. 


The complete source code and executable file for this step in the creation of the 
WINGEX application can be found in the CHAP04\WINGEX2 directory of this book 
CD-ROM. : 


1. Select the Project menu’s Files command. The Project Files dialog box 
appears, as shown in figure 4.7. 


Fig. 4.7 # Project Files 
The Project Files File Na 
dialog box. 


C:\MSVC20\wingex\mainfim.cpp 
MSVC20\wingex\readme. txt 
SVC20\wingex\stdafx.cpp 
SVC20\wingex\wingedoc.cpp 


Niainnes\ minnes con 


2. Set the List Files of Type list box to Library Files, and then use the 
Directories box to find the WING32.LIB file in the C:\WING\LIB direc- 
tory. Double-click WING32.L1B in the File Name box to add it to the 
project. When done, click the Close button. 


The WING32.LIB file tells the Visual C++ linker important information 
about the functions that you’ll be importing from the WinG DLL. 


3. 
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Open the WINGEVW.H file and add the following line near the top of 
the file, right before the CWingexView class declaration: 


#include "c:\wing\include\wing.h" 


WING.H is a header file that contains prototypes for the functions in 
the WinG library. Visual C++’s compiler needs these prototypes in order 
to compile any file that calls WinG functions. 


Add the following code to the WINGEVW.H file, right below the line 
you added in step 3: 


typedef struct BmInfo 


{ 
BITMAPINFOHEADER Header; 
RGBQUAD aColors[256] ; 

} BmInfo; 


This code declares a BITMAPINFO structure for the WinG bitmap. You 
learned about this type of structure in Chapter 2, “Manipulating 
Device-Independent Bitmaps.” 


. Add the following lines to the WINGEVW.H file, in the class 


declaration’s Attributes section, right after the line CWingexDoc* 
GetDocument() ;: 
protected: 

HBITMAP m_hOldBitmap; 

HDC m_hWinGDC; 

BmInfo m_WinGBmInfo; 

void* m_pWinGDibBits; 

LONG m_orientation; 

HPALETTE m_hPalette; 


The preceding lines declare data members in the CWingexView class. You 
learn more about these data members later in this chapter. 


Add the following member function declaration to the CWingexView 
class, placing it in the class’s Implementation section, right after the 
protected keyword: 


void CreateWinGDibPalette() ; 


Load the WINGEVW.CPP file and add the following code to the 
CWingexView Class’s constructor, right after the // TODO: add construc- 
tion code here comment: 


// Check what type of DIB we should use. 
WinGRecommendDIBFormat ( (BITMAPINFO* ) &m_WinGBmInfo) ; 
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// Save the recommended orientation. 
m_orientation = m_WinGBmInfo.Header.biHeight; 


// Fill in the BITMAPINFO structure with values 

// to create a 256-color 300x300 WinG bitmap. 
m_WinGBmInfo.Header.biBitCount = 8; 
m_WinGBmInfo.Header.biCompression = BI_RGB; 
m_WinGBmInfo.Header.biWidth = 300; 
m_WinGBmInfo.Header.biHeight = 300 * m_orientation; 


// Copy the screen colors into the WinG bitmap 
// and create a logical palette. 
CreateWinGDibPalette(); 


// Create a WinG device context. 
m_hWinGDC = WinGCreateDC() ; 


// Create a WinG bitmap compatible with the WinG DC. 
HBITMAP hBitmap = WinGCreateBitmap(m_hWinGDC, 
(BITMAPINFO*)&m_WinGBmInfo, &m_pWinGDibBits) ; 


// Select the WinG bitmap into the WinG DC. 
m_hOldBitmap = 
(HBITMAP)SelectObject(m_hWinGDC, hBitmap) ; 


// Clear the garbage from the WinG bitmap. 
PatBlt(m_hWinGDC, @, ©, 300, 300, BLACKNESS) ; 


This source code sets up the WinG device context and bitmap. You see 
how the code works a little later in this chapter. 


Add the following code to the CWingexView class’s destructor, found in 
the WINGEVW.CPPF file: 


// Select the old bitmap back into the WinG DC. 
HBITMAP hBitmap = 
(HBITMAP)SelectObject(m_hWinGDC, m_hOldBitmap) ; 


// Delete the WinG bitmap that the program created. 
DeleteObject(hBitmap) ; 


// Delete the WinG DC. 
DeleteDC (m_hWinGDC) ; 


// Delete the logical palette. 
DeleteObject(m_hPalette) ; 


The preceding code simply deletes the various objects that the program 
creates. 


Add the following function at the end of the WINGEVW.CPP file, right 
after the // CWingexView message handlers comment: 


void CWingexView: :CreateWinGDibPalette() 
{ 
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// Define a structure for the logical palette. 
struct 


WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256]; 

} logicalPalette = { 0x300, 256 }; 


// Get a device context for the screen. 
HDC hScreenDC = ::GetDC(Q); 


// Load the system palette into the 
// logical palette structure. 
GetSystemPaletteEntries 

(hScreenDC, 0, 256, logicalPalette.aEntries) ; 


// Get rid of the screen DC. 
::ReleaseDC(@, hScreenDC) ; 


// Copy the system colors into the WinG bitmap's 
// color table and set the appropriate flags. 
for(int i = @;i < 256;i++) 
{ 
m_WinGBmInfo.aColors[i].rgbRed = 
logicalPalette.aEntries[i] .peRed; 
m_WinGBmInfo.aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen; 
m_WinGBmInfo.aColors[i].rgbBlue = 
logicalPalette.aEntries[i] .peBlue; 
m_WinGBmInfo.aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = 0; 
} 


// Create the program's logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*)&logicalPalette) ; 


} 
This function sets the WinG bitmap’s color table and creates a logical 


palette from those colors. You see how the code works a little later in 
this chapter. 


10. In the WINGEVW.CPP file, find the OnDraw() function and copy the 
following code into it, right after the // TODO: add draw code for 
native data here comment: 


// Select the logical palette into the window's DC. 
SelectPalette(pDC->m_hDC, m_hPalette, FALSE) ; 


// Tell Windows to remap the system palette with 
// the program's logical palette. 
RealizePalette(pDC->m_hDC) ; 
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// Draw a rectangle on the WinG bitmap. 
Rectangle(m_hWinGDC, 20, 20, 100, 100); 


// Transfer the WinG bitmap to the window's display. 

WinGBitB1lt(pDC->m_hDC, 20, 20, 300, 300, m_hWinGDC, ©, 0); 
The preceding lines draw the window’s display. You see how this code 
works later in the chapter. 


11. Select the Project menu’s ClassWizard command. The MFC ClassWizard 
dialog box appears. 


12. In the Class Name box, select CMainFrame. In the Object IDs box, select 
CMainFrame. Finally, double-click PreCreateWindow in the Messages box 
to add this function to the CMAINFRM.CPP file (see fig. 4.8). 


Fig. 4.8 | _- MFC ClassWizard 
The MFC | 
ClassWizard 
dialog box. 


briefer. If you have trouble with then refer here. 


13. Click ClassWizard’s Edit Code button to jump to the new function, and 
add the following code to the function, right after the // TODO: Add 
your specialized code here and/or call the base class comment: 

// Set the main window's width and height. 


cs.cx 350; 
cs.cy 385; 
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The preceding lines set the width of the application’s main window to 
350 pixels and the height of the window to 385 pixels. 


To compile the program, select the Project menu’s Build command. Visual 
C++ then compiles and links the application. 


Running WINGEX, Version 2 

To run WINGEX, select the Project menu’s Execute command. When you do, 
you see the window shown in figure 4.9. The black square containing the 
white rectangle is the image of the WinG bitmap the program created in 
memory. This bitmap was copied to the screen by the WinGBitB1t() function 
in the CWingexView class’s OnDraw() function. 


= Untitled - wingex eM 5 oe 2 Fig. 4.9 
: WINGEX Version 
2 in action. 


Although WINGEX doesn’t seem to do a heck of a lot, you know that there’s 
a lot more going on than meets the eye. After all, you’re the one who added 
all that weird-looking code to the program, every bit of which does some- 
thing important for a WinG program. In the following section, you'll see 
exactly what that code does. 


Examining the CWingexView Class’s Constructor 
The bulk of this program’s WinG programming can be found in the view 
class’s constructor. 


The first thing the constructor does is ask WinG for the type of bitmap 
that should be used on this system. That’s done by calling the function 
WinGRecommendDIBFormat(), like this: 
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Fig. 4.10 
A top-down 
bitmap in 
memory 


WinGRecommendDIBFormat ( (BITMAPINFO* ) &m_WinGBmInfo) ; 


This function’s single argument is the address of the BITMAPINFO structure that 
will hold the WinG bitmap’s specifications. After calling this function, you 
should examine the BITMAPINFOHEADER’s (which is, remember, the first struc- 
ture in a BITMAPINFO structure) biHeight member. If the value stored in 
biHeight is negative, WinG is suggesting top-down bitmaps. If biHeight is 
positive, WinG is suggesting bottom-up bitmaps. 


Top-Down versus Bottom-Up 

What are top-down and bottom-up bitmaps? I’m glad you asked, because you 
can’t get far with WinG without dealing with these different bitmap types. 
If you came to this book from DOS programming, you probably think of a 
bitmap as graphical information that’s stored in memory with the top line 
of the bitmap stored first and the other lines following as you move upward 
through memory. This type of bitmap is called a top-down bitmap, because 
that’s the way it’s stored in memory, as shown in figure 4.10. As you can see 
in the figure, the bitmap’s origin (point 0,0) is at the top left corner of the 
image where you’d expect it to be. In other words, a top-down bitmap uses 
the same coordinate system as the screen. 


0,0 Lower Memory 


Higher Memory 
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Windows, on the other hand, uses a lot of bottom-up bitmaps, which are 

stored upside down in memory, as shown in figure 4.11. In a bottom-up 
bitmap, the top of the bitmap is stored last in memory, rather than first. 
Effectively, this completely reverses the bitmap’s Y coordinates, placing 

the origin at the bitmap image’s bottom left corner. 


Lower Memory Fig. 4.11 
A bottom-up 
bitmap in memory. 


0,0 
Higher Memory 


Until now, you didn’t need to concern yourself with the difference between 
top-down and bottom-up bitmaps. This is because functions such as Win- 
dows’ StretchDIBits() function, and even WinG’s own WinGBitB1t(), auto- 
matically display bottom-up bitmaps appropriately on the screen. In fact, the 
only time you need to concern yourself with top-down versus bottom-up 
bitmaps is when you plan to write custom drawing routines, as you'll see later 
in this chapter. 


Why does WinG suggest one type of bitmap over another? If you remember, 
WinG profiles the user’s system the first time the user runs a WinG pro- 
gram. Part of this profiling is seeing which type of bitmap—top-down or 
bottom-up—the user’s system handles the fastest. Then, when you call 
WinGRecommendDIBFormat(), WinG tells you which type of bitmap works best, 
by setting the biHeight member of the BITMAPINFOHEADER structure to 1 for 
bottom-up or —1 for top-down. 
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WinG Bitmap Preparations 

Getting back to the view class’s constructor, after calling 
WinGRecommendDIBFormat(), the program saves the recommended 
bitmap orientation in the data member m_orientation: 


m_orientation = m_WinGBmInfo.Header.biHeight; 


Next, the program fills in the BITMAPINFO structure with the values needed to 
create the appropriate bitmap: 
m_WinGBmInfo.Header.biBitCount = 8; 
m_WinGBmInfo.Header.biCompression = BI_RGB; 


m_WinGBmInfo.Header.biWidth = 300; 
m_WinGBmInfo.Header.biHeight = 300 * m_orientation; 


Because WinG currently handles only 8-bit bitmaps, the biBitCount member 
must be 8. Because a WinG bitmap is not compressed, biCompression is set to 
BI_RGB (defined as 0 in WINGDI.H). Finally, the program needs to set the size 
of the bitmap. The height gets stored in biHeight, and the width gets stored 
in biWidth. Notice that biHeight is multiplied by m_orientation, which, at this 
point, is either 1 or -1. This means that a top-down bitmap has a negative 
height and a bottom-up bitmap has a positive height. 


Creating the Palette, Device Context, and Bitmap 

Now, the view’s constructor is almost ready to create the WinG bitmap. First, 
however, the program must create the bitmap’s palette. This is important 
because if you try to create a WinG bitmap with an uninitialized palette, your 
program may act unpredictably. The program creates the bitmap’s palette by 
calling the CreateWinGDibPalette() function: 


CreateWinGDibPalette(); 


The CreateWinGDibPalette() function is defined later in the program. You’ll 
take a detailed look at it then. For now, just assume that this function fills in 
the WinG bitmap’s palette with valid values. 


Once the BITMAPINFO structure is properly initialized, the program calls 
WinGCreateDC() to create a WinG device context: 


m_hWinGDC = WinGCreateDC() ; 


This function, which is part of the WinG API, requires no parameters and 
returns a handle to the device context. This program stores the handle in the 
class data member m_hWinGDC. 
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Finally, the program can create the actual WinG bitmap by calling the WinG 
API’s WinGCreateBitmap() function: 

HBITMAP hBitmap = WinGCreateBitmap(m_hWinGDC, 

(BITMAPINFO*) &m_WinGBmInfo, &m_pWinGDibBits) ; 

This function, which returns a handle to a WinG bitmap that’s compatible 
with the WinG DC, takes as parameters the handle to the WinG DC, a 
pointer to the bitmap’s BITMAPINFO structure, and the address of a void 
pointer into which the function can store the address of the WinG bitmap. 
In this program, the data member m_pWinGDibBits will hold the bitmap’s 
address. 


Finishing Up WinG Initialization 
At this point, the program has a WinG DC and a 300 x 300 WinG bitmap 
that’s compatible with the DC. The next step is to call the Windows’ function 
SelectObject() to select the bitmap into the DC: 

m_hOldBitmap = 

(HBITMAP)SelectObject(m_hWinGDC, hBitmap); 

This function, which returns a handle to the old bitmap (a 1 x 1 mono- 
chrome bitmap that’s always created along with the DC), takes as parameters 
a handle to a WinG DC and a handle to the bitmap. 


The last task completed in the constructor is to paint the WinG bitmap en- 
tirely black, by calling the Windows function PatB1t(): 


PatBlt(m_hWinGDC, @, @, 300, 300, BLACKNESS) ; 


This function takes as parameters a handle to the DC, the X,Y coordinates of 
the rectangle that will be filled with the pattern, the width and height of the 
rectangle, and the raster-operation (ROP) code. The ROP code BLACKNESS fills 
the rectangle with black. Another common code is WHITENESS, which creates a 
white-filled rectangle. 


Examining the OnDraw() Function 

After the constructor has finished its initialization tasks, the WINGEX pro- 
gram has a WinG bitmap ready to go in memory. Unfortunately, just having 
a bitmap in memory doesn’t help much. It also must be displayed on the 
screen. As with most MFC programs, the view class’s OnDraw() function 
handles the display of an application’s data. 
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As you know, the first task an application with a custom palette must com- 
plete is realizing its palette. This is done by first selecting the palette into 
the window’s device context, and then calling the Windows function 
RealizePalette(): 


SelectPalette(pDC->m_hDC, m_hPalette, FALSE) ; 
RealizePalette(pDC->m_hDC) ; 


Next, to demonstrate drawing to a WinG bitmap, OnDraw() calls the Windows 
function Rectangle(): 


Rectangle(m_hWinGDC, 20, 20, 100, 100); 


This function’s arguments are a handle to a DC (in this case, the WinG DC), 
and the left, top, right, and bottom coordinates of the rectangle. Because no 
new brush has been created for the WinG DC, the default white brush will fill 
the rectangle. 


Now, it all comes together when OnDraw() calls the WinG API function 
WinGBitB1t() to copy (or blit, as game programmers say) the WinG bitmap 
from memory to the screen: 


WinGBitB1t(pDC->m_hDC, 20, 20, 300, 300, m_hWinGDC, @, 0); 


This function’s arguments are a handle to the window’s DC, the X,Y coordi- 
nates of the destination rectangle, the width and height of the destination 
rectangle, a handle to a WinG DC, and the X,Y coordinates of the top left 
corner of the rectangle to copy. In this case, the program is blitting the entire 
bitmap, so the width and height are 300, and the source rectangle’s top left 
corner is at 0,0. 


After this function call, the WinG bitmap is displayed in the application’s 
window. The process of transferring the WinG bitmap from memory to the 
screen using the WinGBitB1t() function is as fast as possible for the host sys- 
tem. In fact, it’s usually as fast as blitting is in a DOS program, which is, of 
course, the whole point of using WinG in the first place. 


Remember that WinGBitB1t() knows how to handle both top-down and bottom-up 
bitmaps. It knows which is which by looking at the BITMAPINFOHEADER’s biHeight 
member. If WinG finds a negative value there, it knows that it’s dealing with a top- 
down bitmap. Otherwise, WinG treats the image as a bottom-up bitmap. The only 
thing you have to do (unless you start writing custom drawing routines) is make sure 
that the biHeight member contains the appropriate value, based on the recommen- 
dation received from the WinGRecommendDibFormat () function. 
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Examining the CreateWinGDibPalette( ) Function 

As you learned previously, you don’t want to try to create your WinG bitmap 
until its BITMAPINFO structure contains a valid palette. Failure to set the palette 
first may result in unpredictable behavior and even program crashes. In the 
WINGEX program, the palette is set by calling the CreatewinGPalette() 
function. 


The Logical Palette Structure 
The CreateWinGDibPalette() function first defines a structure for the 
application’s logical palette: 


struct 


{ 
WORD Version; 


WORD NumberOfEntries; 
PALETTEENTRY aEntries[256]; 
} logicalPalette = { 0x300, 256 }; 


You learned about this structure in Chapter 2, “Manipulating Device- 
Independent Bitmaps.” 


Getting the System Colors 

Because the program will set the WinG bitmap’s palette to the system’s pal- 
ette, the function next calls the Windows function GetDC() to get a handle to 
the screen’s DC: 


HDC hScreenDC = ::GetDC(Q); 


This function, which returns a handle to a DC, requires as its single argument 
a window’s handle. The screen’s window handle is always 0. 


After getting a handle to the screen’s DC, a quick call to the Windows 
function GetSystemPaletteEntries() copies the system palette into the 
PALETTEENTRY array: 


GetSystemPaletteEntries 
(hScreenDC, @, 256, logicalPalette.aEntries) ; 


This function’s parameters are a handle to a device context (in this case, the 
screen’s), the index of the first palette entry to receive, the number of palette 
entries to receive, and a pointer to the PALETTEENTRY array that will receive the 
colors. (If you make this last parameter 0, GetSystemPaletteEntries() returns 
the number of colors in the system palette.) 
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Tip 

Although your 
program’s speed 
may suffer, you 
can force WinG to 
always use a top- 
down bitmap. To 
do this, just ignore 
the bitmap orien- 
tation recom- 
mended by 
WinGRecommendDib - 
Format() and set 
the WinG bitmap’s 
BITMAPINFOHEADER 
member biHeight 
to a negative 
value. 
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Because of the direct way the WINGEX program handles palettes, it must be run on a 
256-color system. 


Once the program has the system colors stored in the PALETTEENTRY array, it 
no longer needs the screen DC, so it releases it by calling the Windows func- 
tion ReleaseDC(): 


:1ReleaseDC(@, hScreenDC) ; 


This function’s first argument is the handle of the window that owns the DC. 
Again, the screen DC is always 0. The second argument is the handle of the 
DC to be released. 


Copying the System Colors and Creating the Palette 
Now, the CreateWinGPalette() function can copy the system colors into the 
palette array. It does this with a for loop: 
for(int i = 0; i < 256; i++) 
{ 
m_WinGBmInfo.aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed; 
m_WinGBmInfo.aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen; 
m_WinGBmInfo.aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue; 
m_WinGBmInfo.aColors[i].rgbReserved = Q; 


logicalPalette.aEntries[i].peFlags = 0; 
} 


The final step is to create a logical palette from the array. The program does 
this by calling the Windows function CreatePalette(): 


m_hPalette = 
CreatePalette((LOGPALETTE*)&logicalPalette) ; 


This function returns a handle to a logical palette and requires as its single 
argument a pointer to a LOGPALETTE structure. 


Examining the CWingexView Class’s Destructor 
Before the program ends, it must delete any objects that it created on the 
heap. It does this in CWingexView’s destructor. 
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The destructor first selects the original monochrome bitmap back into the 
WinG device context: 

HBITMAP hBitmap = 

(HBITMAP)SelectObject(m_hWinGDC, m_hOldBitmap) ; 

It’s not really important that you reselect the old bitmap. What is important 
is that you deselect the WinG bitmap before you delete it. The easiest way to 
do this is to reselect the old bitmap, which doesn’t need to be deleted by the 
program. 


Windows 95 and Windows NT are a lot less strict about how they deal with device 
contexts and the objects selected into those device contexts. For example, under 
Windows 3.1, there can be no more than five DCs created simultaneously. So, when 
programming for Windows 3.x, you have to be sure to release DCs as quickly as 
possible. Windows 95 and Windows NT have no such limitations. However, if you 
want your 32-bit programs to run properly under Windows 3.1, as well as under 
Windows NT and Windows 95, you have to deal with the lowest common denomina- 
tor, being sure to follow the programming restrictions inherent in Windows 3.1. 


After deselecting the WinG bitmap, it can be deleted safely: 
DeleteObject(hBitmap) ; 


Next, the destructor deletes the WinG bitmap by calling the Windows func- 
tion DeleteObject(): 


DeleteObject(hBitmap) ; 
The WinG DC is deleted by calling the Windows function DeleteDC(): 
DeleteDC(m_hWinGDC) ; 


Finally, the program deletes the logical palette by calling the Windows func- 
tion DeleteObject() with the palette’s handle: 


DeleteObject(m_hPalette) ; 
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Now that you have a WinG DC and bitmap set up in memory and can dis- 
play the WinG bitmap on the screen, it’s time to add two important features 
to your WinG program: a custom drawing routine and the ability to create an 
identity palette. You’ll learn more about these enhancements after you create 
the program. 
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The au e sou codi and executable file for this step in the creation of the 
-~ WINGEX application can be found in the CHAP04\WINGEX3 directory of this book’s 
CD-ROM. 


1. Copy the CDIB.CPP and CDIB.H files into WINGEX’s project directory. 
(You'll find CDIB.CPP and CDIB.H on this book’s CD-ROM, in the 
CHAP02\SHOWDIB directory.) 


2. Select the Project menu’s Files command. The Project Files dialog box 
appears, as shown in figure 4.12. In the File Name list box, double-click 
the CDIB.CPP file to add it to the project, and then click the Close but- 
ton to finalize your choice. 


3. Load the WINGEVW.CPP file and add the following line to the class’s 
constructor, immediately before the code you placed there previously: 
// Load the SCENE.BMP file. 
m_pSceneDib = new CDib("scene.bmp") ; 


This line loads the bitmap file SCENE.BMP and attaches it to a CDib 
object. 


Fig. 4.12 | Project Files 
The Project Files 
dialog box. 


c ANS Calwingss WW NBEDO CPP 
pinges WINGEVY, LPP. 


4. Again in the class’s constructor, comment out the call to 
CreateWinGPalette() and substitute the following function call: 
// Create an identity palette based on the 


// CDib object's 256-color palette. 
CreateIdentityPalette(&m_WinGBmInfo, m_pSceneDib) ; 
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The line you commented out called a function that created a 

logical palette from the system’s 256-color palette. The function 
CreateIdentityPalette(), which you'll add to the program later in these 
steps, creates an identity palette from the CDib object’s color table. You 
will learn about identity palettes later in this chapter. 


Add the following lines to the class’s destructor, immediately following 
the other code you placed there previously: 


// Delete the CDib object holding SCENE.BMP. 
delete m_pSceneDib; 


These lines ensure that the SCENE.BMP bitmap is deleted before the 
program ends. 


Comment out the call to Rectangle() in the OnDraw() function. 


Because this version of the program draws the SCENE.BMP image on 
the screen, you don’t want to mess up the display with a rectangle. 


Add the following lines to the class’s OnDraw() function, after the call to 
Rectangle() that you just commented out: 


// Copy the scene to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, m_pSceneDib) ; 


This line calls a custom drawing routine that copies the SCENE.BMP 
image to the WinG bitmap. You add the CopyDIBToWinG() function to 
the program in a later step. 


Add the following function to the end of the WINGEVW.CP?P file: 


void CWingexView: :CopyDIBToWinG 
(BYTE* m_pWinGDibBits, CDib* pDib) 

{ 
// Get the bitmap's width and height. 
UINT srcWidth = pDib->GetDibWidth() ; 
UINT srcHeight = pDib->GetDibHeight() ; 


// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr(); 


// Copy data from the source bitmap to the WinG 
// bitmap. 
for (UINT row=0; row<srcHeight; ++row) 
for (UINT col=@; col<srcWidth; ++col) 
{ 
LONG index = row * srcWidth + col; 
m_pWinGDibBits[index] = pDibBits[ index]; 
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This function is a custom drawing routine that copies the image data 
from a CDib object directly to a WinG bitmap. You'll learn more about 
the CopyDIBToWinG() function later in this chapter. 


9. Add the following function to the end of the WINGEVW.CPP file: 


void CWingexView: :CreateIdentityPalette 
(BmInfo* winGBmInfo, CDib* pDib) 
{ 
struct 
{ 
WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256] ; 
} logicalPalette = {0x300, 256}; 


// Get the screen DC. 
HDC Screen = ::GetDC(Q); 


// Copy Windows' 20 standard system colors 
// into the new logical palette. 
GetSystemPaletteEntries 
(Screen, ©, 10, logicalPalette.aEntries) ; 
GetSystemPaletteEntries 
(Screen, 246, 10, logicalPalette.aEntries + 246); 


// Get rid of the screen DC. 
::ReleaseDC(Q,Screen) ; 


// Copy the standard 20 system colors into 
// the WinG bitmap's color table. 
for(int i = 0; i < 10; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i] .peRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i] .peBlue; 
winGBmInfo->aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = 0; 


winGBmInfo->aColors[i + 246].rgbRed = 
logicalPalette.aEntries[i + 246].peRed; 
winGBmInfo->aColors[i + 246].rgbGreen = 
logicalPalette.aEntries[i + 246].peGreen; 
winGBmInfo->aColors[i + 246].rgbBlue = 
logicalPalette.aEntries[i + 246].peBlue; 
winGBmInfo->aColors[i + 246].rgbReserved = 0; 


logicalPalette.aEntries[i + 246].peFlags = 0; 
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// Get a pointer to the source bitmap's color table. 
LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr(); 


// Copy the source bitmap's color table into both 
// the WinG bitmap color table and 
// into the new logical palette. 
for(i = 10; i < 246; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed = 
pColorTable[i] .rgbRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen = 
pColorTable[i] .rgbGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i] .rgbBlue; 
winGBmInfo->aColors[i].rgbReserved = Q; 
logicalPalette.aEntries[i].peFlags = 
PC_NOCOLLAPSE; 


// Create the logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*) &logicalPalette) ; 


} 


This function creates an identity palette from a CDib object’s color table. 


You learn about identity palettes later in this chapter. 


10. Load the WINGEVW.H file and add the following line to the top of the 
file, after the line #include "c:\wing\include\wing.h" that you already 
placed there: 


#include "cdib.h" 
This line allows the CWingexView class to use the CDib class. 


11. Also in WINGEVW.H, add the following line to the class’s protected 
Attributes section, right after the data members you placed there 
previously: 


CDib* m_pSceneDib; 


This line declares the data member m_pSceneDib as a pointer to a CDib 
object. 


12. Add the following function declarations to the WINGEVW.H file in the 
Implementation section, right after the other function declaration you 
placed there previously: 
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Fig. 4.13 
WINGEX version 3 
with a top-down 
WinG bitmap. 


void CopyDIBToWinG(BYTE* m_pWinGBmBits, CDib* pDib) ; 
void CreateIdentityPalette(BmInfo* winGBmInfo, 
CDib* pDib); 
These lines declare CopyDIBToWinG() and CreateIdentityPalette() to be 
member functions of the CWingexView class. 


13. Copy the SCENE.BMP file into WINGEX’s project directory. (You'll find 
SCENE.BMP on this book’s CD-ROM, in the CHAPO04\WINGEX 
directory.) 


To compile the program, select the Project menu’s Rebuild All command. 
Visual C++ then compiles and links the application. 


Running WINGEX, Version 3 

To run WINGEX after you compile it, select the Project menu’s Execute com- 
mand. When you do, you see the window shown in figure 4.13—or, you may 
see a window like figure 4.14, with an upside-down display. Which you see 
depends on the type of WinG bitmap the WinGRecommendDIBFormat() func- 
tion suggested. If it suggested a standard, bottom-up bitmap, indicated 

by a biHeight of 1, your window’s image should be right-side up. If 
WinGRecommendDIBFormat() recommended a top-down bitmap, indicated 

by a value of -1 in biHeight, your display will be upside down. 


‘Untitled - wingex 
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Fig. 4.14 
WINGEX version 3 
with a bottom-up 
WinG bitmap. 


More Details about Top-Down Bitmaps 

Your display might come out upside down because your simple, bitmap- 
blitting function CopyDIBToWinG() doesn’t yet know how to deal with top- 
down WinG bitmaps. The origin of a top-down bitmap is in the top left 
corner, whereas the origin of a standard DIB is the bottom left corner. Unless 
your custom drawing routine knows to reverse the Y values in the case of a 
top-down bitmap, the image comes out upside down. 


Look at figure 4.15. The top pair of images shows a bottom-up WinG bitmap 
and a standard DIB as they’re stored in memory. Although the origins of both 
bitmaps are in the bottom left corner, CopyDIBToWinG() copies bytes directly 
into the WinG bitmap, from low memory to high memory, yielding an up- 
side-down image in the WinG bitmap. But, when you call WinGBitB1t(), 
which recognizes the WinG bitmap as being bottom-up, it automatically 
reverses the image in the window’s display. Thus, the image looks correct on 
the screen (see fig. 4.16). 


But if the WinG bitmap is stored top-down, the origin moves to the top left 
comer. CopyDIBToWinG() still copies the bitmap directly over, with no transla- 
tion, so the image in the WinG bitmap is upside down, just as it was in the 
bottom-up bitmap. Now, however, when you call WinGBitB1t() to display the 
bitmap on the screen, it sees that the WinG bitmap is top-down and does not 
reverse the bitmap on the display. Thus, the display in the window comes out 
upside down. If CopyDIBToWinG() is to handle top-down WinG bitmaps, then, 
it must be able to blit bitmaps as shown in the bottom two images of figure 
4.15. 
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Fig. 4.15 
Blitting data 
between WinG 
bitmaps and DIBs. 


0,0 


WinG Bitmap i Bottom-Up DIB 
(Bottom-Up) 


WinG Bitmap r Bottom-Up DIB 
(Top-Down) 
Fig. 4.16 
Displaying 
bottom-up 
bitmaps. 
0,0 0,0 5 
Source Bitmap WinG Bitmap Screen After 
(Bottom-Up) (Bottom-Up) WinGBitBIt() 


The bottom line on top-down and bottom-up bitmaps is that you must always blit 
the source bitmap into the WinG bitmap such that the origin of both bitmaps is 


. With a bottom-up WinG bitmap, both the WinG and the source bitmaps’ 


origins are in the bottom left corner, so a direct copy maintains the orientation. 
However, a top-down WinG bitmap’s origin is in the top left corner, whereas the 
source DIB’s origin is usually in the bottom left corner. This means the source image 
must be mirrored vertically in order to maintain the correct orientation in the WinG 


_ bitmap. 


In the next version of the WINGEX program, you'll add the ability to handle 
top-down bitmaps, as well as correct a few other things that CopyDIBToWinG() 


doesn’t do quite right. 


For the time being, if you ended up with a reversed display, you can correct it 


by changing the line 
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m_WinGBmInfo.Header.biHeight 300 * m_orientation; 


to 


m_WinGBmInfo.Header.biHeight 300; // * m_orientation 


which forces WinG to use a standard bottom-up bitmap. If you ended up 
with an upright display but want to see what the reversed display looks like, 
just change the 300 in the preceding line to -300, which forces WinG to use a 
top-down bitmap. 


The scene you see in the display comes from the Aztec Adventure game that you'll 

_ be developing later in the book. The artwork was composed by Maurice Molyneaux, 
who has been creating computer-game graphics for many years. One of his most 
recent commercial games is Rules of Engagement 2, created by Omnitrend and dis- 
tributed by Impressions. 


Examining the CreateldentityPalette( ) Function 

In Chapter 2, “Manipulating Device-Independent Bitmaps,” you learned that 
Windows has to do a lot of work to keep every open window looking as good 
as possible. Specifically, Windows must map each running application’s logi- 
cal palette to the system palette. 


Windows’ process of mapping palettes is complicated and time-consuming. If 
you use a lot of graphics-intensive applications, you know that it can take a 
few seconds for Windows to straighten out the display each time a new win- 
dow is activated. Obviously, if your Windows game is going to run fast, it 
can’t get bogged down with all this palette mapping. That’s why WinG pro- 
grams usually create an identity palette. 


An identity palette is nothing more mysterious than a logical palette that per- 
fectly matches the system palette. If an application’s logical palette contains 
exactly the same colors as the system palette, Windows can forgo the palette- 
mapping process. By avoiding the palette mapping, an application can run 
much faster. In this version of the WINGEX program, the function 
CreateIdentityPalette() handles the important task of creating an identity 
palette. 


Maintaining the Standard Windows Colors 

The first step in creating an identity palette is to get the system’s standard 20 
colors, which are located in the bottom 10 and top 10 positions of a 256- 
color palette: 
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HDC Screen = ::GetDC(Q); 
GetSystemPaletteEntries 

(Screen, @, 10, logicalPalette.aEntries) ; 
GetSystemPaletteEntries 

(Screen, 246, 10, logicalPalette.aEntries + 246); 
: :ReleaseDC(0,Screen) ; 


Windows uses these 20 standard colors for drawing things such as windows, 
menus, dialog boxes, and controls. If you want Windows to keep looking like 
Windows, it’s important that you not change these 20 colors. 


After getting the 20 standard system colors, the CreateIdentityPalette() 
function copies those 20 colors into the WinG bitmap’s color table. The 
peFlags structure member for these colors is set to 0. 

for(int i = 0; i < 10; i++) 


{ 
winGBmInfo->aColors[i].rgbRed = 


logicalPalette.aEntries[i].peRed; 
winGBmInfo->aColors[i].rgbGreen = 

logicalPalette.aEntries[i] .peGreen; 
winGBmInfo->aColors[i].rgbBlue = 

logicalPalette.aEntries[i].peBlue; 
winGBmInfo->aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = 0; 


winGBmInfo->aColors[i + 246].rgbRed = 
logicalPalette.aEntries[i + 246].peRed; 
winGBmInfo->aColors[i + 246].rgbGreen = 
logicalPalette.aEntries[i + 246].peGreen; 
winGBmInfo->aColors[i + 246].rgbBlue = 
logicalPalette.aEntries[i + 246] .peBlue; 
winGBmInfo->aColors[i + 246].rgbReserved = 0; 


logicalPalette.aEntries[i + 246].peFlags = 0; 


Copying the Source Bitmap’s Color Table 
Next, the CreateIdentityPalette() function gets a pointer to the CDib object’s 
color table: 


LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr () ; 


Because you want the CDib object’s image to look correct on the screen, 
you must use its colors to create the identity palette. So, the 
CreateIdentityPalette() function copies the middle 236 colors from 

the CDib object’s color table into the logical palette and into the WinG 
bitmap’s color table. Only when all three sets of colors match will you have 
an identity palette: 
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for(i = 10; i < 246; i++) 
{ 


winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed = 
pColorTable[i].rgbRed; 

winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen = 
pColorTable[i].rgbGreen; 

winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i] .rgbBlue; 

winGBmInfo->aColors[i].rgbReserved = 0; 
logicalPalette.aEntries[i].peFlags = 

PC_NOCOLLAPSE ; 
} 


Notice the peFlags structure member for these 236 colors. According to the 
WinG developer’s kit, this flag should be set to PC_NOCOLLAPSE in order to 
attain an identity palette. However, in order for this to work, you must be 
sure that none of the colors in your palette matches any of the upper ten 
system colors. For example, if your color at palette index 100 has an RGB 
value of 255,0,0, you can’t get an identity palette because the color at palette 
index 249—a Windows system color—also has an RGB value of 255,0,0. 


Due to these complexities of how Windows’ palette manager works, 

most people have discovered that trying to get an identity palette using 
PC_NOCOLLAPSE is tougher than dancing with a rattlesnake. It turns out that it’s 
much easier to use the PC_RESERVED flag, which prevents Windows from map- 
ping any palette entries to these colors. However, using PC_RESERVED causes 
other problems when you try to respond to WM_PALETTECHANGED messages. 
Specifically, your window may be unable to redraw itself properly when run- 
ning in the background. 


Finally, when the WinG bitmap’s color table, the CDib object’s color table, 
and the logical palette have all been filled with exactly the same colors, 
CreateIdentityPalette() creates the logical, identity palette: 

m_hPalette = 

CreatePalette((LOGPALETTE*)&logicalPalette) ; 

Now, the data member m_hPalette holds a handle to the identity palette, 
which must be selected and realized before drawing images to the 
application’s window. 
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Examining the CopyDIBToWinG( ) Function 

WinG applications run fastest when the program avoids calls to slow, gener- 
alized functions such as those found in Windows’ GDI (Graphics Device 
Interface), and, instead, do much of their drawing with custom-written draw- 
ing functions. Often, such custom functions are written in assembly language 
in order to squeeze every bit of speed out of the machine. 


Because this isn’t a book on assembly language, you'll stick with C++ for your 
custom drawing routines. However, if you’re familiar with assembly language, 
you should be able to convert these C++ functions to assembly language with 
little difficulty. (If you’d like to see an example of an assembly language cus- 
tom drawing function, check out the FAST32.ASM file included with the 
WinG developer’s kit.) 


Copying between the Source and WinG Bitmaps 

In the WINGEX program, you need a custom routine only to blit the CDib 
object’s image to the WinG bitmap. Because the WinG bitmap and the CDib 
object’s image are exactly the same size in this version of WINGEX, copying 
the image data is trivial, as you can see in the CopyDIBToWinG() function. 


This function takes as its two parameters a pointer to the WinG bitmap’s 
drawing surface and a pointer to the CDib object that holds the image data 
you want to blit to the WinG bitmap. The pointer to the WinG bitmap’s 
drawing surface is provided by the WinGCreateBitmap() function when you 
create your WinG bitmap. You can also obtain this pointer by calling the 
WinGGetDIBPointer() function, like this: 


void* pWinGSurface = 
WinGGetDIBPointer (hWinGBitmap, pHeader) ; 


In the preceding function call, hWinGBitmap is the WinG bitmap’s handle and 
pHeader is a pointer to a BmInfo structure (declared in WINGEVW.H). If this 
pointer is 0, the function merely returns a pointer to the WinG bitmap’s 
drawing surface. If pHeader is a valid pointer, the function also fills the 
BITMAPINFO structure with appropriate values for the WinG bitmap. 


In the body of the CopyDIBToWinG() function, the program first retrieves the 
width and height of the CDib object’s image: 


UINT srcWidth = pDib->GetDibWidth() ; 
UINT srcHeight = pDib->GetDibHeight() ; 


Next, CopyDIBToWinG() gets a pointer to the CDib object’s image data: 
g P J 8 


BYTE* pDibBits = pDib->GetDibBitsPtr(); 
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The program uses the width and height of the bitmap in nested for loops to 
copy the image data, byte by byte, from the CDib object’s image to the WinG 
bitmap’s drawing surface: 


for (UINT row=0; row<srcHeight; ++row) 
for (UINT col=0; col<srcWidth; ++col) 


LONG index = row * srcWidth + col; 
m_pWinGDibBits[index] = pDibBits[index]; 


Indexing Bitmap Data 

The calculation that yields index is pretty simple in this version of the 
CopyDIBToWinG() function, thanks mostly to the facts that each pixel of a 256- 
color image is represented by a single byte of information and that both the 
source and destination bitmaps are exactly the same size. 


In the for loops, the program uses the m_pWinGDibBits and pDibBits pointers 
as array addresses, which allows the program to treat the WinG bitmap and 
the CDib object’s image as arrays of bytes. To calculate an index into this array 
for any particular byte is a simple matter of multiplying the zero-based row 
number by the bitmap’s width and then adding the zero-based column num- 
ber to the product. 


For example, suppose the bitmaps involved in the copy are both 10 x 10, as 
shown in figure 4.17. The bitmap on the left is the bitmap you created with 
the WinGCreateBitmap() function, and the bitmap on the right is the CDib 
object’s image that you want to blit to the WinG bitmap. The rows and col- 
umns of the bitmaps are numbered from 0 to 9, but each byte in memory is 
stored contiguously with the data for column 0, row 0 in the first byte and 
the data for column 9, row 9 in the last byte. This means each byte can be 
indexed with a value from 0 to 99, as shown in the figure. 
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In the case of the bitmaps in figure 4.17, srcHeight would be 10 and srcWidth 
would be 10. The first time through the loop, row equals O and col equals O. 
So, the following calculations are done in the body of the loop: 


index = row * srcWidth + col 
=@* 10+0 
= 0 


So, index equals O, and the line 
m_pWinGDibBits[index] = pDibBits[ index]; 


copies the first byte pointed to by pDibBits to the first byte pointed to by 
m_pWinGDibBits. 


The next time through the loop, row equals O and col equals 1. The calcula- 
tions look like this: 
row * srcWidth + col 


=0* 10+1 
=1 


index 


So the second byte pointed to by pDibBits gets copied into the second byte 
pointed to by m_pWinGDibBits. 


Similar calculations continue until the inner for loop makes col equal to 

sreWidth (in this case, srcWidth is 10) and the loop finishes. This begins the 
outer loop’s second iteration, making row equal to 1. The inner loop begins 
again, making col equal to 0. The calculations for index now look like this: 


index = row * srcWidth + col 
=1* 10+0 
= 10 


As you can sée, this index is the first byte of the second row in the bitmaps. 
The next time through, the inner loops give these calculations: 


index = row * srcWidth + col 
=1%* 10+ 1 
= 11 


The indexes being generated now are for the second row in the bitmaps. This 
looping continues, row by row, until both loops run out. The final calcula- 
tion looks like this: 


index = row * srcWidth + col 
=9* 10+9 
= 99 


If I seem to be belaboring a simple calculation, it’s because it’s important 
that you understand these basics. As you modify CopyDIBToWinG() to handle 
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various sized bitmaps, as well as top-down or bottom-up bitmaps, things 
get much more complicated. 


Improving the CopyDIBToWinG( ) Function 

The source bitmaps you'll want to copy to a WinG bitmap are rarely going to 
be the same size as the WinG bitmap. This means that you must have a cus- 
tom routine that can copy any size bitmap to the WinG drawing surface. This 
is the first improvement you’ll make to the CopyDIBToWinG() function. 


Unless otherwise stated, all of the enhancements presented in this section assume 
that you're working with a bottom-up WinG bitmap. Once you've developed the 
basic bitmap-copying algorithms, you'll learn how to modify them for top-down 
WinG bitmaps. 


Handling Bitmaps of Differing Sizes 

Suppose that your WinG bitmap is still 10 x 10, but your source bitmap is 
now only 3 x 3, as shown in figure 4.18. If you try to index the WinG bitmap 
with the same indexes you calculate for the source bitmap, you’ll end up with 
strange results, as the figure shows. 


Fig. 4.18 
Straight copying 
doesn’t work for 
bitmaps of 
different sizes. 
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Because the source bitmap is smaller than the WinG bitmap, you actually 
have to calculate two indexes in order to prevent distorting the image you’re 
copying. The bytes at indexes 0, 1, 2, 3, 4, 5, 6, 7, and 8 of the source bitmap 
must be mapped into the WinG bitmap at byte indexes 0, 1, 2, 10, 11, 12, 20, 
21, and 22, respectively, so you end up with the bitmaps shown in figure 
4.19. 
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Fig. 4.19 

A smaller bitmap 
correctly copied 
into a larger one. 
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WinG Bitmap 


To solve this problem for the bitmaps in figure 4.18, you need to skip seven 
bytes in every row of the WinG bitmap. This is easy to do, simply by adding 
row times 7 to the source bitmap’s indexes. For the source bitmap indexes 0, 
1, and 2 in row 0, you add 0 times 7, which leaves you with the original in- 
dexes. For the indexes 3, 4, and 5 in row 1, you add 1 times seven, which 
gives you 10, 11, and 12, exactly where you must map these bytes into the 
WinG bitmap. 


Generalizing the Formula 

Of course, your bitmaps are going to have many different sizes, so you need 
to generalize the formula. What exactly is 7 in the preceding scenario? It’s 
the width of the WinG bitmap minus the width of the source bitmap. The 
index into the WinG bitmap is calculated by modifying the original calcula- 
tions like this: 


srcIndex 
dstIndex 


row * srcWidth + col; 
srcIndex + row * (dstWidth - srcWidth) ; 


Here, srcIndex is the index in the source bitmap, and dstIndex is the index in 
the WinG bitmap. Using these calculations, you can easily copy a bitmap 
smaller than the WinG bitmap into the WinG bitmap. Keep in mind, how- 
ever, that the preceding calculations assume that the source bitmap is never 
larger than the WinG bitmap. To solve that problem means handling clipping 
(determining what to draw and what not to draw), which slows down the 
code. When you write a custom routine like this, you avoid giving it any 
abilities you don’t absolutely need. That keeps the code running as fast as 
possible. 
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Never use the CopyDIBToWinG() function to copy a source bitmap that’s larger than 
the WinG bitmap. If you do, your program will very likely crash. 


If you plug the preceding calculation into the bitmap-copying loop of 
CopyDIBToWinG(), you get something like this: 


for (UINT row=@; row<srcHeight; ++row) 
for (UINT col=0; col<srcWidth; ++col) 
{ 
DWORD srcIndex 
(DWORD)row * srcWidth + (DWORD)col; 
DWORD dstIndex = 
srcIndex + (DWORD)row * 
(WINGDIBWIDTH - srcWidth) ; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 


} 


Notice that the function is now using DworDs (double words) for many of the 
calculations. Bitmaps can be extremely large. Multiplying such large numbers 
can give you results that overflow a small data type such as an integer. No- 
tice, also, the WINGDIBWIDTH constant. This constant represents the width of 
the WinG bitmap. You'll see its counterpart, WINGDIBHEIGHT, soon. 


Giving a Bitmap a New Destination 
Suppose you want to blit the source bitmap to any location in the WinG 
bitmap, such as shown in figure 4.20. 


Fig. 4.20 
Copying the 
source bitmap to 
any location in 
the WinG bitmap. 
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This task is actually much easier than you might think. To move the image to 
the right in the WinG bitmap, just add some value to the index. For example, 
if you want the source bitmap to appear at column 5 of the WinG bitmap, 
just add five to dstIndex. Similarly, to move the bitmap down in the WinG 
bitmap, just add the product of the destination row number and the WinG 
bitmap’s width. For example, to blit the source bitmap to the WinG bitmap’s 
row 5, just add five times the WinG bitmap’s width to dstIndex. You end up 
with calculations like this: 


srcIndex = row * srcWidth + col; 
dstIndex = srcIndex + row * (dstWidth - srcWidth) + 
dstX + (dstY * dstWidth) ; 


The bitmap-copying loop now looks like this: 


for (UINT row=0; row<srcHeight; ++row) 
for (UINT col=@; col<srcWidth; ++col) 


DWORD srcIndex = 

(DWORD) row * srcWidth + (DWORD) col; 
DWORD dstIndex = srcIndex + (DWORD)row * 

(WINGDIBWIDTH - srcWidth) + 

dstX + (dstY * WINGDIBWIDTH) ; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 


} 


Of course, now there are two more pieces of information that you must pass 
into the CopyDIBToWinG() function: the X and Y coordinates in the WinG 
bitmap to which you’re going to copy the source bitmap. CopyDIBToWinG()’s 
prototype now looks like this, with dstx and dstY being the function’s new 
parameters: 


void CWingexView: :CopyDIBToWinG 
(BYTE* m_pWinGDibBits, UINT dstX, UINT dstY, CDib* pDib) 


Copying to a Bottom-Up Bitmap Correctly 

If you were to use the CopyDIBToWinG() function as it stands now, you’d 
quickly discover the effect that bottom-up bitmaps have on your custom 
drawing routines. For example, figure 4.21 shows the result you get when you 
blit two standard bottom-up bitmaps to the screen. The background scene 
comes out fine because it’s the same size as the WinG bitmap, but the smaller 
bitmap ends up in the bottom of the WinG bitmap instead of the top. 


When you think about it, this makes perfect sense. The CopyDIBToWinG() func- 
tion copies the source bitmap, from the lower to higher addresses, directly to 
the upside-down WinG bitmap. Then, when WinGBitB1t() copies the WinG 
bitmap to the screen, it flips the image, placing the smaller bitmap in the 
bottom left corner (see fig. 4.22). 
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| = Untitled - wingex Fig. 4.21 

e Hee The result of 
copying a DIB toa 
bottom-up WinG 
bitmap without 
translation. 


0,0 Fig. 4.22 
The process of 
copying a DIB toa 
bottom-up WinG 
bitmap without 
translation. 
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(Bottom-Up) 


To blit the source bitmap to the WinG bitmap’s origin, you must translate 
the indexes. Because the previous calculations are getting a little long and 
complex, now consider a different approach. Rather than calculate dst Index 
in terms of srcIndex, how about calculating both in terms of their own coor- 
dinates? Because all the fancy footwork must be done with the Y coordinates 
(the rows), the following calculations will first calculate the appropriate Y 
coordinate for both bitmaps and then determine the indexes from those. 


Call these translated Y coordinates newSrcy for the source bitmap and newDstY 
for the WinG bitmap. At this point, calculating newSrcy is easy. It’s just the 
current row: 


newSrcY = row; 
srcIndex = newSrcY * srcWidth + col; 


The newDstyY variable, though, must be translated so that the source bitmap 
gets copied to the bottom-up WinG bitmap’s origin and so doesn’t end up in 
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the bottom corner of the display. This translation turns out to be as simple as 
subtracting the height of the source bitmap from the height of the WinG 
bitmap: 

newDstY = dstHeight - srcHeight; 


But don’t forget that you have dstX and dstY, which control where in the 
WinG bitmap the source bitmap gets copied. You can invert dstY just by 
giving it a negative sign: 

newDstY = dstHeight - srcHeight - dstyY; 


And, don’t forget that these calculations are taking place inside a nested for 
loop that’s looping through all rows and columns of the bitmap. The current 
Y coordinate is represented by the loop variable row, which you must add to 
the new Y coordinate: 


newDstY = dstHeight - srcHeight - dstY + row; 


Now, you can calculate the actual index into the WinG bitmap in terms of its 
own coordinates: 


dstIndex = newDstY * dstWidth + col + dstX; 


Notice that this calculation adds in the current column number, as well as 
dstX, which controls how far to the right the source bitmap should appear in 
the WinG bitmap. The new loop now looks like this: 


for (UINT row=0; row<srcHeight; ++row) 
for (UINT col=0; col<srcWidth; ++col) 


{ 
DWORD newSrcyY = row; 
DWORD srcIndex = newSrcY * srcWidth + col; 
DWORD newDstY = 
WINGDIBHEIGHT - srcHeight - dstY + row; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstX; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 
} 


Using these calculations in CopyDIBToWinG(), you get the display shown in 
figure 4.23. Now you're cooking! Figure 4.24 shows the process that leads to 
the screen shown in figure 4.23. 
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= Untitled - wingex > BER Fig. 4.23 

The result of 
copying a DIB to a 
bottom-up WinG 
bitmap after 
translating the Y 
coordinates. 


0,0 Fig. 4.24 
The process of 
copying a DIB to a 
bottom-up WinG 
bitmap after 
Source Bitmap translating the Y 
coordinates. 


0,0 
WinG Bitmap Screen After WinGBitBIt() 
(Bottom-Up) 


Translating for a Top-Down WinG Bitmap 

As I mentioned previously, all the preceding calculations assume that you’re 
working with a bottom-up WinG bitmap. If WinG recommended a top-down 
bitmap, your screen would look like figure 4.25 after you copied the bitmaps 
using CopyDIBToWinG(). In the figure, the entire display is upside down. Figure 
4.26 illustrates the problem. To fix it, the source Y coordinate must be in- 
verted, whereas the destination Y coordinate must not be (which it is in the 
current version of CopyDIBToWInG()). 


130 


Fig. 4.25 

The result of 
copying a DIB toa 
top-down WinG 
bitmap after 
inverting the 
destination Y 
coordinate and 
not inverting 
the source Y 
coordinate. 


Fig. 4.26 

The process of 
copying a DIB toa 
top-down WinG 
bitmap after 
inverting the 
destination Y 
coordinate and 
not inverting 
the source Y 
coordinate. 


Chapter 4—Programming with WinG 


To translate the source bitmap’s Y coordinate so that the bitmap gets in- 
verted, you need only subtract the current row number from the bitmap’s 
height (the —1 is needed because the Y coordinates are zero-based, but 
srcHeight isn’t. That is, a 300 x 300 bitmap has a srcHeight of 300, but its 
highest Y coordinate is 299): 


newSrcY = srcHeight - row - 1; 


But, you want to do this translation only when you’re dealing with a top- 
down WinG bitmap. In the program, the CWingexView class’s data member 
m_orientation is 1 when the program has a bottom-up bitmap and -1 when 
the program has a top-down bitmap, so the entire translation ends up like 
this: 

newSrcY = row; 


if (m_orientation == -1) 


newSrcY = srcHeight - row - 1; 
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To handle the destination Y coordinate, just add dsty to row. After all, now 
you're dealing with a top-down bitmap, so reversing the Y coordinate is 
unnecessary. 


if (m_orientation == -1) 
newDstY = row + dstY; 


The new loop now looks like this: 


for (UINT row=@; row<srcHeight; ++row) 
for (UINT col=®; col<srcWidth; ++col) 


{ 
DWORD newSrcyY = row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - 1; 
DWORD srcIndex = newSrcY * srcWidth + col; 
DWORD newDstY = 
WINGDIBHEIGHT - srcHeight - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstxX; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex]; 
} 


Figure 4.27 illustrates how the CopyDIBToWinG() function now works with a 
top-down WinG bitmap. 
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Copying Only Part of a Source Bitmap 

Now, there’s one final twist you need to handle in order to have a fully work- 
ing bitmap copier: You must enable the CopyDIBToWinG() function to copy all 
or any part of the source bitmap to the WinG bitmap. Why? Because you'll 
frequently have many smaller bitmaps groups together in a single, larger one. 
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Fig. 4.28 
Animation frames 
grouped ina 
bitmap. 


In the simple animation you’ll soon add to WINGEX, for example, the eight 
frames that make up the animation are grouped together in one large bitmap, 
as shown in figure 4.28. In order to use these frames, CopyDIBToWinG() must 
be able to find each frame based on its X,Y coordinate. 


To copy only a part of a source bitmap (we’ll call this bitmap part a frame, for 
the sake of convenience), you first need four new pieces of information: the 
column and row at which the frame is located in the source bitmap, and the 
width and height of the frame. These values will be represented by the vari- 
ables frmx, frmY, frmW, and frm, respectively. But, remember that DIBs are 
stored bottom-up, so you must translate the Y coordinate (frmy). Subtracting 
the height of the frame and the frame’s Y coordinate from the full height of 
the source bitmap takes care of this translation: 


newSrcY = srcHeight - frmH - frmyY; 


Don’t forget that you need to add the current row, which is controlled by the 
for loop, to newSrcy: 


newSrcY = srcHeight - frmH - frmY + row; 


You also have to modify the translation that’s done to the source bitmap’s Y 
coordinate in the case of a top-down WinG bitmap, by subtracting frmy: 


if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
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These final changes complete the CopyDIBToWin@() function. The complete 
function looks like this: 
void CWingexView: :CopyDIBToWinG 


(BYTE* m_pWinGDibBits, UINT dstX, UINT dstY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frmH) 


{ 
// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight() ; 
// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr(); 
// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=@; row<frmH; ++row) 
for (UINT col=0; col<frmW; ++col) 
{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmx; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstX; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex]; 
} 
} 


Notice that the for loops no longer use srcHeight and srcWidth as their limits. 
The loops now use frmH and frmw, which enables the loop to copy only the 
portion of the bitmap requested by the user. When copying an entire bitmap, 
srcHeight and frmH, as well as srcWidth and frmv, will be the same. But often, 
they'll be very different. In any case, though, frmH must never be larger than 
srcHeight, and frmw must never be larger than srcWidth. Likewise, dstx and 
dstY must fall within the boundaries of the WinG bitmap. 


There are a few other caveats of which you should be aware. As mentioned 
before, you must never try to copy, to the WinG bitmap, a source bitmap 
that’s larger than the WinG bitmap. (Copying a frame from a larger bitmap is 
okay, as long as the frame is smaller than the WinG bitmap.) Such a copy will 
surely crash your computer. 


The ability to copy a bitmap or frame to any position in the WinG bitmap 
also creates a little time bomb that could crash your computer. You must 
make sure that you don’t try to copy such data outside the boundaries of the 
WinG bitmap. Copying a bitmap as shown in figure 4.29 is a major no-no. 
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Fig. 4.29 

You cannot blit 
bitmaps or frames 
that extend 
beyond the 
boundaries of the 
WinG bitmap. 


Source Bitmap 


WinG Bitmap 


Finally, for technical reasons I won’t go into here (it has to do with byte 
boundaries), the width of your source bitmaps must always be a multiple of 
eight (although you can copy a frame of any size from a bitmap). 
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Now that you have a workable version of CopyDIBToWinG(), you can actually 
use WinG to do something useful to you as a game programmer: create a 
simple animation. In the steps that follow, you'll create the final version of 
the WINGEX program. By the time you’re done, you’ll know most of what 
you need to know to use WinG in your Windows games. 


creation of 
~ WINGEX application can be found in the CHAPO4\WINGEX directory of this book's. 
CD-ROM. 


1. Load the WINGEVW.CPP file and place the following lines in the 
CWingexView class’s constructor, right after the line m_pSceneDib = new 
CDib("scene.bmp") that you placed there previously. 


// Load the bitmap containing the animation frames. 
m_pPropDib = new CDib("prop.bmp") ; 


This code takes care of loading the bitmap that contains the animation 
frames and associates the bitmap with a CDib object. 


2. In the constructor, comment out the following lines: 


m_WinGBmInfo.Header.biWidth = 300; 
m_WinGBmInfo.Header.biHeight = 300 * m_orientation; 
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and replace them with 


m_WinGBmInfo.Header.biWidth = WINGDIBWIDTH; 
m_WinGBmInfo.Header.biHeight = 
WINGDIBHEIGHT * m_orientation; 


Here, you’re just replacing the hard-coded WinG bitmap width and 
height with constants that not only make it easier to change the size 
of the bitmap, but also make the code easier to read. 


Add the following lines right after the lines you modified in step 3: 


// Initialize the frame counter. 
m_frameNum = 0; 


This code initializes the variable that keeps track of which animation 
frame is currently displayed. 


Add the following lines to the CWingexView class’s destructor, immedi- 
ately following the lines you placed there previously: 


// Delete the CDib object holding PROP.BMP. 
delete m_pPropDib; 


This code deletes the new CDib object that was created from the 
PROP.BMP file. 


In the class’s OnDraw() function, comment out the line 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, m_pSceneDib) ; 
and replace it with 


CopyDIBToWinG((BYTE*)m_pWinGDibBits, @, @, 
m_pSceneDib, 0, 0, 300, 300); 
This code calls the new version of CopyDIBToWinG() in order to blit the 
background scene to the WinG bitmap. 


Comment out the old version of CopyDIBToWinG() and add the new 
version listed here to the end of the WINGEVW.CPP? file: 


void CWingexView: :CopyDIBToWinG 
(BYTE* m_pWinGDibBits, UINT dstX, UINT dstY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frmH) 


// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight(); 


// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr() ; 
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// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=0; col<frmW; ++col) 
{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmX; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstX; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 


} 
7. Add the following function to the end of the WINGEVW.CPP file: 


void CWingexView: :CopyDIBToWinGTrns 
(BYTE* m_pWinGDibBits, UINT dstX, UINT dstY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frm, 
UINT trnsColor) 


// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth(); 
DWORD srcHeight = pDib->GetDibHeight() ; 


// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr(); 


// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=0; col<frmW; ++col) 


{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmyY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmX; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstX; 
if (pDibBits[srcIndex] != trnsColor) 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex]; 
} 


9. 


10. 


11. 
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The function CopyDIBToWinGTrns() is a slightly modified version of 
CopyDIBToWinG() that enables you to transfer bitmaps with a transparent 
background to the WinG bitmap. You’ll learn more about this function 
later in the chapter. 


Use ClassWizard to add the OnCreate() function to the CWingexView 
class, as shown in figure 4.30. OnCreate() is a message-response func- 
tion for the WM_CREATE message. 


Fig. 4.30 
Adding the 
OnCreate( ) 
function to the 
CWingex View 
class. 
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Click ClassWizard’s Edit Code button and add the following lines to the 
OnCreate() function, immediately following the // TODO: Add your 
specialized creation code here comment: 

// Start a Windows timer. 

SetTimer(1, 100, 0); 
This code starts a Windows timer that sends WM_TIMER messages to the 
application every 100 milliseconds. You learn about Windows timers 
later in this chapter. 


Use ClassWizard to add the OnDestroy() function to the CWingexView 
class, as shown in figure 4.31. OnDestroy() is a message-response func- 
tion for the WM_DESTROY message. 


Click ClassWizard’s Edit Code button and add the following lines to the 
OnDestroy() function, immediately following the // TODO: Add your 
message handler code here comment: 
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// Destroy the Windows timer. 
KillTimer (1); 


This code shuts down the Windows timer that was started in the 
OnCreate() function. 


Fig. 4.31 ‘ClassWizard 
Adding the Vea 
OnDestroy( ) 
function to the 
CWingexView class. 


12. Use ClassWizard to add the OnTimer() function to the CWingexView class, 
as shown in figure 4.32. OnTimer() is a message-response function for 
the WM_TIMER message. 


Fig. 4.32 
Adding the 
OnTimer( ) 
function to the 
CWingex View | 

| : WM_RBUTTONUP 
class. | WM_SETCURSOR 


WM_SETFOCUS 
WM_SHOWWIND: 
WM SIZE 


ON_WM_CREATE 
ON_WM_DESTROY 
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13. Click ClassWizard’s Edit Code button and add the following lines to the 
OnTimer() function, immediately following the // TODO: Add your mes- 
sage handler code here and/or call default comment: 

// Increment the animation frame counter. 
m_frameNum += 1; 


if (m_frameNum > 7) 
m_frameNum = 0; 


UINT x, y; 


// Get the coordinates for the next frame. 
switch (m_frameNum) 


{ 
case 0: x = 1; y = 1; break; 
case 1: x = 163; y = 1; break; 
case 2: x = 325; y = 1; break; 
case 3: x = 1; y = 163; break; 
case 4: x = 163; y = 163; break; 
case 5: x = 325; y = 163; break; 
case 6: x = 1; y = 325; break; 
case 7: X = 163; y = 325; 

} 


// Update the WinG bitmap by restoring the scene 

// where the last frame appeared and then 

// copying the new frame to the WinG bitmap. 

CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 70, 70, 
m_pSceneDib, 70, 70, 230, 230); 

CopyDIBToWinGTrns((BYTE*)m_pWinGDibBits, 70, 70, 
m_pPropDib, x, y, 160, 160, 255); 


// Get a device context for the window's client area. 
CDC* pClientDC = new CClientDC(this) ; 


// Select the logical palette into the window's DC. 
SelectPalette(pClientDC->m_hDC, m_hPalette, FALSE); 


// Tell Windows to remap the system palette with 
// the program's logical palette. 
RealizePalette(pClientDC->m_hDC) ; 


// Transfer the WinG bitmap to the window's display. 
WinGBitBlt(pClientDC->m_hDC, 20, 2@, WINGDIBWIDTH, 
WINGDIBHEIGHT, m_hWinGDC, @, 0); 


// Delete the window's DC. 
delete pClientDC; 


These lines perform the actual animation. You'll learn how they work 
later in this chapter. 
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14. 


15. 


16. 


17. 


Load the WINGEVW.H file and add the following constant definitions 
to the top, immediately following the BmInfo structure declaration: 


const WINGDIBWIDTH = 300; 
const WINGDIBHEIGHT = 300; 


These lines define constants for the WinG bitmap’s width and height. 
To change the size of your WinG bitmap in the WINGEX program, just 
change the values of these constants. 


Add the following lines to the Attributes section of the CWingexView 
class’s declaration, right after the other data members you listed there 
previously: 

CDib* m_pPropDib; 

UINT m_frameNum; 


These lines declare m_pPropDib and m_frameNum as protected data mem- 
bers of the CWingexView class. 


In the Implementation section, comment out the old CopyDIBTowInG() 
function declaration and add the following lines in its place: 
void CopyDIBToWinG(BYTE* m_pWinGBmBits, 
UINT dstX, UINT dstY, CDib* pDib, 
UINT frmX, UINT frmY, UINT frmW, UINT frm) ; 
void CopyDIBToWinGTrns(BYTE* m_pWinGBmBits, 
UINT dstX, UINT dstY, CDib* pDib, 
UINT frmX, UINT frmY, UINT frmW, UINT frm, 
UINT trnsColor) ; 


These lines declare the modified CopyDIBToWinG() function and the new 
CopyDIBToWinG@Trns() function as members of the CWingexView class. 


Copy the PROP.BMP file into WINGEX’s project directory. (You'll 
find PROP.BMP on this book’s CD-ROM, in the CHAPO4\WINGEX 
directory.) 


To compile the program, select the Project menu’s Build command. Visual 
C++ then compiles and links the application. 


Running WINGEX, Version 4 

To run WINGEX after you compile it, select the Project menu’s Execute com- 
mand. When you do, you see the window shown in figure 4.33. Of course, 
what you can’t see in the figure is that the thing that looks like a sickly sun- 
flower is actually a set of rotating blades, a nasty trap for just about any 
dungeon. 
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Although this animation example isn’t exactly up to arcade-game standards, 
it does demonstrate the basic technique behind using WinG for animation. 
In a fast-action arcade game, the CopyDIBToWinG() function would be way too 
slow (it’s running only about ten frames a second). You would probably have 
to optimize it and write it in assembly language. 


The point is, however, that to perform such animations, you have to com- 
plete a number of steps: 


1. Create a WinG bitmap in memory. 
2. Compose the animation frames onto this bitmap. 


3. Use WinGBitB1t() (or WinGStretchB1t(), which allows bitmap scaling) to 
blit the finished frame to the screen. 


You already know the basics of creating a WinG application. In the sections 
that follow, you’ll study more of the details. 


— = 
P Untitled - wingex 


Examining the CopyDIBToWinGTrns() Function 

The first thing you may be curious about is the new CopyDIBToWinGTrns() 
function, which seems a heck of a lot like CopyDIBToWinG(), but has an extra 
parameter. 


That extra parameter, trnsColor, is the index in the color table of the trans- 
parent color. You need to know this value because, in order to transfer non- 
rectangular images to the WinG bitmap, you need to do a transparent blit. 


Fig. 4.33 

The dungeon 
scene with 
rotating blades. 
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Fig. 4.34 
The dungeon 
scene without 


transparent blits. 


What’s a transparent blit? It might be easier to show you what a transparent 
blit isn’t. Take a look at figure 4.34. This is the type of screen you'd see if 
you tried to do WINGEX’s animation using CopyDIBToWinG() rather than 
CopyDIBToWinGTrns(). The bitmap’s background wipes out the scene that’s 
supposed to show behind the rotating blades. 


The solution to this problem is to treat the background color—in this case, 
white, which has an index of 255 in the color table—as a transparent color. 
In other words, when blitting the bitmap, the function should just ignore 
any pixel that has the value 255. 


That’s exactly what CopyDIBToWinGTrns() does. In fact, that’s really the only 
difference between CopyDIBToWinGTrns() and CopyDIBToWinG(). Before copying 
a pixel from the source bitmap to the WinG bitmap, CopyDIBToWinGTrns () 
checks the pixel’s value. If its value is different from trnsColor, the function 
copies the pixel; otherwise, the function ignores the pixel: 


if (pDibBits[srcIndex] != trnsColor) 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 


This has the effect of making a bitmap’s background transparent, as if you 
can see right through to the scene behind. 


Why have two different functions that do almost the same thing? Because 
checking for a transparent color for every pixel in a blit takes a lot of time. 
Transparent blits, which are slower, should be used only when necessary. By 
having two separate functions, regular blits don’t get saddled with the trans- 
parent blit’s extra sluggishness. 
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Examining the OnCreate() Function 

When your program creates its view, it constructs a window object of the 
CWingexView class. Much of your program’s initialization can be done in the 
class’s constructor, just as you would with any other class. However, attached 
to a view-window class is an actual Windows window. Some functions re- 
quire that this window be created and valid before those functions can be 
used. 


A good place to do any type of initialization that requires a valid window 
handle is in the OnCreate() function, which responds to the WW_CREATE mes- 
sage. Windows sends the WM_CREATE message to an application when it’s about 
to create the window. At this point, your window has a valid handle. You 
used ClassWizard to add OnCreate() to the WINGEX program, and then 
modified the code to suit the program’s needs. 


You'll never call the OnCreate() function from within your program. It’s 
called only by MFC when the window receives a WM_CREATE message. In the 
preceding function, WINGEX creates a Windows timer, which it uses to time 
the animation frames. The call to SetTimer() looks like this: 


SetTimer(1, 100, 0); 


SetTimer() is an MFC function that encapsulates the Windows API function 
of the same name. The function’s three parameters are a timer ID (whatever 
value you’d like), the number of milliseconds between timer events, and a 
pointer to a callback function. If this pointer is 0, Windows automatically 
sends the WM_TIMER messages to the window that created the timer. 


What does the timer do once you start it? It simply sends WM_TIMER mes- 
sages to your program. How fast you receive these messages depends on 
SetTimer()’s second argument. In the preceding case, WINGEX receives a 
WM_TIMER message every 100 milliseconds. 


Examining the OnTimer() Function 
You may have already guessed that it’s the OnTimer() function that MFC calls 
whenever it receives a timer message. 


In OnTimer(), the program first increments the animation frame counter, 
which determines which frame is to be displayed next on the screen: 
m_frameNum += 1; 


J 
if (m_frameNum > 7) 
m_frameNum = 
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Notice that, if m_frameNum is larger than 7, the program sets it back to 0. In 
this way, the same eight animation frames are displayed over and over. 


After determining the next frame number, the program gets the coordinates 
in the source bitmap for the next frame to display: 


UINT x, y; 

switch (m_frameNum) 

{ 
case 0: x = 1; y = 1; break; 
case 1: x = 163; y = 1; break; 
case 2: x = 325; y = 1; break; 
case 3: x = 1; y = 163; break; 
case 4: x = 163; y = 163; break; 
case 5: x = 325; y = 163; break; 
case 6: x = 1; y = 325; break; 
case 7: x = 163; y = 325; 

} 


Next, the program replaces the part of the background scene that was covered 
by the last animation frame: 

CopyDIBToWinG((BYTE*)m_pWinGDibBits, 70, 70, 

m_pSceneDib, 70, 70, 230, 230); 

In this line, only the part of the background image located at 70,70, and with 
a width and height of 160, is being blitted to the screen. This is the only 
portion of the display that has to be fixed. Sure, you could redisplay the en- 
tire scene, but that would take longer and would slow the animation. 


After restoring the background scene, the program blits the next animation 
frame to the WinG bitmap: 

CopyDIBToWinGTrns((BYTE*)m_pWinGDibBits, 70, 70, 

m_pPropDib, x, y, 160, 160, 255); 

Here, the frame gets copied to location 70,70 in the WinG bitmap. The ani- 
mation-frame image is copied from the PROP.BMP bitmap, at the coordinates 
now stored in x and y. The image is 160 x 160, and treats color number 255 
as transparent. 


Now that the new scene is assembled in memory, it’s time to display it on the 
screen. But, in order to write to the screen, the program needs a device con- 
text for the window: 


CDC* pClientDC = new CClientDC(this) ; 


This line constructs a new CClientDC object and returns a pointer to the ob- 
ject in pClientDC. CClientDC is an MFC class that encapsulates client-window 
device contexts. Once you have the pointer to the CClientDCc object, you can 
use it to display data in your application’s window. 
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Before displaying the new image, however, you must select and realize the 
application’s logical palette, which ensures that the image on the screen is 
displayed with the correct colors: 
SelectPalette(pClientDC->m_hDC, m_hPalette, FALSE); 
RealizePalette(pClientDC->m_hDC) ; 
Now, finally, the program can blit the new animation frame from the WinG 
bitmap to the window: 


WinGBitBlt(pClientDC->m_hDC, 20, 20, WINGDIBWIDTH, 
WINGDIBHEIGHT, m_hWinGDC, ©, @); 


To finish things, OnTimer() deletes the DC it created: 
delete pClientDC; 


Keep in mind that the OnTimer() function is really the heart of this program. 
It gets called every 100 milliseconds. So, ten times a second, it constructs a 
new frame of animation and displays it on the screen. 


Examining the OnDestroy( ) Function 

The last new function in this final version of WINGEX is OnDestroy(), which 
is the counterpart to OnCreate(). Just as Windows calls OnCreate() when it’s 
ready to create your view window, so Windows calls OnDestroy() when it’s 
about to destroy the window. OnDestroy(), then, is the perfect place to clean 
up anything you may have done in OnCreate(), which is exactly what 
WINGEX’s version of OnDestroy() does. 


This function’s only task is to call KillTimer() to turn off the Windows timer 
that was started in OnCreate(): 


KillTimer (1); 


KillTimer() is an MFC function that encapsulates the Windows API function 
of the same name. Its single argument is the ID of the timer you want to kill. 
Make sure you kill every Windows timer you start! 


The Listings 


Following are the complete listings for the files in the WINGEX project that 
you modified over the course of this chapter. In these listings, code that you 
added manually is shown between double lines of slash characters. Code that 
you added using ClassWizard is listed normally—that is, it is not shown be- 
tween double lines of slash characters. Files that were created by AppWizard, 
but which you did not modify, are not shown here. If you’d like to know 
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what the unlisted files contain, load them from disk using Visual C++ or 
some other text editor. 


Listing 4.1 MAINFRM.CPP—The Implementation File for the 


CMainFrame Class 


// mainfrm.cpp : implementation of the CMainFrame class 
// 


#include "stdafx.h" 
#include "wingex.h" 


#include "mainfrm.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED_CODE THIS FILE[] = _ _FILE_ _; 
#endif 


PILTTTTTTT TTT AAT AAA TTT 
CMainFrame 


IMPLEMENT_DYNCREATE(CMainFrame, CFrameWnd) 


BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) 
//{{AFX_MSG_MAP (CMainFrame) 
// NOTE - the ClassWizard will add and remove mapping macros here. 
// DO NOT EDIT what you see in these blocks of generated code ! 
/ /}}AFX_MSG_MAP 
END_MESSAGE_MAP( ) 


TLTTTTTTTT TTT TTT TATA TATA AAA ELALLA 
CMainFrame construction/destruction 


CMainFrame: :CMainFrame() 


{ 
// TODO: add member initialization code here 
} 
CMainFrame: :~CMainFrame() 
{ 
} 


PRIIT UITATI TAA ATTA TAA ATT TTT TTL 
CMainFrame diagnostics 


The Listings 


#ifdef _DEBUG 
void CMainFrame::AssertValid() const 


{ 
CFrameWnd: :AssertValid(); 
} 
void CMainFrame: :Dump(CDumpContext& dc) const 
{ 
CFrameWnd: :Dump(dc) ; 
} 


#endif //_DEBUG 


FUTTTTTTTTTT TTT TTT TTT TTA AAA AAA AAA AAT 
// CMainFrame message handlers 


BOOL CMainFrame: :PreCreateWindow(CREATESTRUCT& cs) 


{ 
// TODO: Add your specialized code here and/or call the base class 


TTTTTTTTTTAT TTT TTT TAT TTT AT 
ENICAN OTCE ILITI AAT 
// START CUSTOM CODE 

TILTTTTTTTTT TTT TTT TTT TATA TT 
FITTTTTTTTTTT TTT TTT TTT 


// Set the main window's width and height. 
cs.cx 350; 
cs.cy 385; 


TILTTTTTTTTTTTT TTT TTT TATA ATT 
TTTTTTTTTTTTT TTT TTT TTT TTA TAT 
// END CUSTOM CODE 

[IIIA 
LITEIT ILICI IITA CILA TLIN ITIL. 


return CFrameWnd: :PreCreateWindow(cs) ; 


|S ESSE SEES 


Listing 4.2 WINGEVW.H—Header File for the CWingexView Class 


// wingevw.h : interface of the CWingexView class 
CIIILE TTT TTT TTT TT TTT ATT TTT AATAL 


ITTTTTTTTTTTTTTT TTT TTT TATA TTT 
IIIT 
// START CUSTOM CODE 

CIILA AAN TAANILE AAAA AAI 
//IIIIIIIIIIIII TTT TTT TTT TTT TT 


(continues) 
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Listing 4.2 Continued 


#include "c:\wing\include\wing.h" 
#include "cdib.h" 


typedef struct BmInfo 


BITMAPINFOHEADER Header; 
RGBQUAD aColors[256]; 
} BmInfo; 


const WINGDIBWIDTH = 300; 
const WINGDIBHEIGHT = 300; 


[IIIIIIII IIIA 
[IIIIIIIIIII IIIA 
// END CUSTOM CODE 

[ILILILILIL IIIA 
[IIIIIII IIIA IIIA 


class CWingexView : public CView 

{ 

protected: // create from serialization only 
CWingexView() ; 
DECLARE_DYNCREATE (CWingexView) 


// Attributes 


public: 
CWingexDoc* GetDocument() ; 


[IIIIIII I TTT TTT TATA AAA 
[IIIIIIIIII TTT TTT TTT AAT 
// START CUSTOM CODE 

[IILI II IIIN 
FITITTLTTTT TTT TTT TATA TATA 


protected: 
HBITMAP m_hOldBitmap; 
HDC m_hWinGDC; 
BmInfo m_WinGBmInfo; 
void* m_pWinGDibBits; 
LONG m_orientation; 
HPALETTE m_hPalette; 
CDib* m_pSceneDib; 
CDib* m_pPropDib; 
UINT m_frameNum; 


[IILI TTT TATA TTT ATA AAT AAT 
[ILILILILIL IILI ILIITA 
// END CUSTOM CODE 

[ILILILILIL 
[ILILILILIL IIIA 


// Operations public: 


// Overrides 


The Listings 


// ClassWizard generated virtual function overrides 
/ /{{AFX_VIRTUAL (CWingexView) 
public: 
virtual void OnDraw(CDC* pDC) ; 
// overridden to draw this view protected: 
/ /}}AFX_VIRTUAL 


// Implementation 
public: 
virtual ~CWingexView(); 
#ifdef _DEBUG 
virtual void AssertValid() const; 
virtual void Dump(CDumpContext& dc) const; 
#endif 


protected: 


[I/III III IIIT 
[IIIIIIIIIII III IIIT 
// START CUSTOM CODE 

[/IIIIIII III TATA TATA TAA 
[/IIIIIII III TTT TATA TATA TTL 


void CreateWinGDibPalette() ; 
//void CopyDIBToWinG(BYTE* m_pWinGBmBits, CDib* pDib) ; 
void CreateIdentityPalette(BmInfo* winGBmInfo, 
CDib* pDib) ; 
void CopyDIBToWinG(BYTE* m_pWinGBmBits, 
UINT dstX, UINT dstY, CDib* pDib, 
UINT frmX, UINT frmY, UINT frmW, UINT frmH); 
void CopyDIBToWinGTrns(BYTE* m_pWinGBmBits, 
UINT dstX, UINT dstY, CDib* pDib, 
UINT frmX, UINT frmY, UINT frmW, UINT frmH, 
UINT trnsColor) ; 


[ILILILILIL IIIA 
[I/III IIIA 
// END CUSTOM CODE 

TIITTTTTTTTT TTT TT TATA AAT TATA TTT 
[IIIIIIII IIIA TATA 


// Generated message map functions 
protected: 
/ /{{AFX_MSG (CWingexView) 
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct) ; 
afx_msg void OnDestroy(); 
afx_msg void OnTimer(UINT nIDEvent) ; 
//}}AFX_MSG 
DECLARE_MESSAGE_MAP( ) 


}; 


#ifndef _DEBUG // debug version in wingevw.cpp 
inline CWingexDoc* CWingexView: :GetDocument () 

{ return (CWingexDoc*)m_pDocument; } 
#endif 


FLTTTTTTTTTL TTT TATA TTT TATA AAT TAA ALT ATA AAT AA AAA TAA AAA TATA AAA 
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Listing 4.3 WINGEVW.CPP—Implementation File for the 


CWingex View Class 


// wingevw.cpp : implementation of the CWingexView class 
// 


#include "stdafx.h" 
#include "wingex.h" 


#include "wingedoc.h" 
#include "wingevw.h" 


#ifdef DEBUG 

#undef THIS _FILE 

static char BASED CODE THIS _FILE[] = _ _FILE_ _; 
#endif 


FITTITTTTTT TTT TTT TTT TTT TTT TTA TTA TT ITTI 
// CWingexView 


IMPLEMENT_DYNCREATE (CWingexView, CView) 


BEGIN_MESSAGE_MAP(CWingexView, CView) 

//{{AFX_MSG_MAP (CWingexView) 
ON_WM_CREATE ( ) 
ON_WM_DESTROY ( ) 
ON_WM_TIMER() 
//}}AFX_MSG_MAP 

END_MESSAGE_MAP ( ) 


AINIIN TTT TTT TTT TTT TTT ATTA ATTA 
// CWingexView construction/destruction 


CWingexView: :CWingexView( ) 
{ 
// TODO: add construction code here 


TITLTTTTTTTT TTT TTT TTT TTT TTT 
TIALE ALLTAL 
// START CUSTOM CODE 

TITETTTTTTTTTTTTT TTT TTT TTT TTT 
TIITII ALAA TTT TATA TT 


// Load the SCENE.BMP file. 
m_pSceneDib = new CDib("scene.bmp") ; 


// Load the bitmap containing the animation frames. 
m_pPropDib = new CDib("prop.bmp") ; 


// Check what type of DIB we should use. 
WinGRecommendDIBFormat ( (BITMAPINFO* ) &m_WinGBmInfo) ; 


// Save the recommended orientation. 
m_orientation = m_WinGBmInfo.Header.biHeight; 


} 


The Listings 


// Fill in the BITMAPINFO structure with values 
// to create a 256-color 300x300 WinG bitmap. 
m_WinGBmInfo.Header.biBitCount = 8; 
m_WinGBmInfo.Header.biCompression = BI_RGB; 
//m_WinGBmInfo.Header.biWidth = 300; 
//m_WinGBmInfo.Header.biHeight = 300 * m_orientation; 
m_WinGBmInfo.Header.biWidth = WINGDIBWIDTH; 
m_WinGBmInfo.Header.biHeight = 

WINGDIBHEIGHT * m_orientation; 


// Copy the screen colors into the WinG bitmap 
// and create a logical palette. 
//CreateWinGDibPalette() ; 


// Create an identity palette based on the 
// CDib object's 256-color palette. 
CreateIdentityPalette(&m_WinGBmInfo, m_pSceneDib) ; 


// Create a WinG device context. 
m_hWinGDC = WinGCreateDC() ; 


// Create a WinG bitmap compatible with the WinG DC. 
HBITMAP hBitmap = WinGCreateBitmap(m_hWinGDC, 
(BITMAPINFO*) &m_WinGBmInfo, &m_pWinGDibBits) ; 


// Select the WinG bitmap into the WinG DC. 
m_hOldBitmap = 
(HBITMAP)SelectObject(m_hWinGDC, hBitmap) ; 


// Clear the garbage from the WinG bitmap. 
PatBlt(m_hWinGDC, ©, 2, 300, 300, BLACKNESS) ; 


// Initialize the frame counter. 
m_frameNum = 0; 


PITIE AAA MAALAT EAEE LI 
[ILILILILIL IIIA ILIITA 
// END CUSTOM CODE 

[ILILILILIL IIIA 
[ILILILILIL IIIN 


CWingexView: :~CWingexView() 


{ 


FITTLTTLT TTT TTT ATTA TTA TATA AAT ATT TTL 
[ILILILILIL I IILI 
// START CUSTOM CODE 

FILET TTTTTTTAT TATA TATA AAA AAA 
PETINTA ILITI TEO AAA AAT ATT ATT 


// Select the old bitmap back into the WinG DC. 
HBITMAP hBitmap = 
(HBITMAP)SelectObject(m_hWinGDC, m_hOldBitmap) ; 


// Delete the WinG bitmap that the program created. 
DeleteObject (hBitmap) ; 


(continues) 
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Listing 4.3 Continued 


} 


// Delete the WinG DC. 
DeleteDC (m_hWinGDC) ; 


// Delete the logical palette. 
DeleteObject(m_hPalette) ; 


// Delete the CDib object holding SCENE.BMP. 
delete m_pSceneDib; 


// Delete the CDib object holding PROP.BMP. 
delete m_pPropDib; 


FTITTTTITTTTT TTT TTT TTT ATTA TATA TTT 
FITPTTTTTTTTTT ATT TTT TATA 
// END CUSTOM CODE 

VAISI CETATENIA AITITE 
LIALTAT EILIA CAAT EI 


VIALNEIAT IIAL AAA ANIN AATAL IN TAA AAA AAA AAA 
CWingexView drawing 


void CWingexView::0nDraw(CDC* pDC) 


{ 


CWingexDoc* pDoc = GetDocument(); 
ASSERT_VALID(pDoc) ; 


// TODO: add draw code for native data here 


TLTTTTITITITTT TTT TTT AAAA EEA TTT 
TLTLTTTTTTTTTT TTT TTT TTT TAT 
// START CUSTOM CODE 

TITLTTTTTTTTTT TTT TTT TATA 
PAILLA TA AAA TTT TTT TTA TTT 


// Select the logical palette into the window's DC. 
SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 


// Tell Windows to remap the system palette with 
// the program's logical palette. 
RealizePalette(pDC->m_hDC) ; 


// Draw a rectangle on the WinG bitmap. 
//Rectangle(m_hWinGDC, 20, 20, 100, 100); 


// Copy the scene to the WinG bitmap. 

//CopyDIBToWinG( (BYTE*)m_pWinGDibBits, m_pSceneDib) ; 

CopyDIBToWinG( (BYTE*)m_pWinGDibBits, @, Q, 
m_pSceneDib, ©, 0, 300, 300); 


// Transfer the WinG bitmap to the window's display. 
WinGBitB1t(pDC->m_hDC, 20, 20, 300, 300, m_hWinGDC, ©, 0); 


The Listings 


[ILILILILIL 

[ILILILILIL IIIA 

// END CUSTOM CODE 

[IIIIIIIII IIIT 

[IIIIIIIIIII IIIT 
} 


PITTTLTTTAL ALAA AAA ALAA AAA AT AAA AAA AAA AAA AAA AAA AAA A ATA ATA AAT TL 
CWingexView diagnostics 


#ifdef _DEBUG 
void CWingexView: :AssertValid() const 


{ 
CView: :AssertValid() ; 
} 
void CWingexView: :Dump(CDumpContext& dc) const 
{ 
CView: :Dump(dc) ; 
} 


CWingexDoc* CWingexView::GetDocument() // non-debug version is inline 


ASSERT (m_pDocument ->IsKindOf (RUNTIME_CLASS (CWingexDoc) ) ) ; 
return (CWingexDoc*)m_pDocument; 


} 
#endif //_DEBUG 


TULLTTLTLTT TTT TA TAA A TL 
CWingexView message handlers 


[IIIIILIIII INIIAI 
[IIIIIIIIIII IIIA 
// START CUSTOM CODE 

[ILILILILIL IIIT 
[ILILILILIL IIIENA 


void CWingexView: :CreateWinGDibPalette() 

{ 
// Define a structure for the logical palette. 
struct 


WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256] ; 

} logicalPalette = { 0x300, 256 }; 


// Get a device context for the screen. 
HDC hScreenDC = ::GetDC(Q); 


// Load the system palette into the 
// logical palette structure. 
GetSystemPaletteEntries 

(hScreenDC, ©, 256, logicalPalette.aEntries) ; 


(continues) 
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Listing 4.3 Continued 


// Get rid of the screen DC. 
::ReleaseDC(@, hScreenDC) ; 


// Copy the system colors into the WinG bitmap's 
// color table and set the appropriate flags. 
for(int i = @0;i < 256;i++) 
{ 
m_WinGBmInfo.aColors[i].rgbRed = 
logicalPalette.aEntries[i] .peRed; 
m_WinGBmInfo.aColors[i].rgbGreen = 
logicalPalette.aEntries[i] .peGreen; 
m_WinGBmInfo.aColors[i].rgbBlue = 
logicalPalette.aEntries[i] .peBlue; 
m_WinGBmInfo.aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = Q; 
} 


// Create the program's logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*) &logicalPalette) ; 


} 


/* 

void CWingexView: :CopyDIBToWinG 
(BYTE* m_pWinGDibBits, CDib* pDib) 

{ 
// Get the bitmap's width and height. 
UINT srcWidth = pDib->GetDibWidth() ; 
UINT srcHeight = pDib->GetDibHeight() ; 


// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr() ; 


// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<srcHeight; ++row) 
for (UINT col=@; col<srcWidth; ++col) 
{ 
LONG index = row * srcWidth + col; 
m_pWinGDibBits[index] = pDibBits[ index]; 


} 
=/ 


void CWingexView: :CopyDIBToWinG 
(BYTE* m_pWinGDibBits, UINT dstX, UINT dstyY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frmH) 


// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight() ; 


// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr() ; 
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// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=0; col<frmW; ++col) 
{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmX; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstxX; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex]; 


} 


void CWingexView: :CreateIdentityPalette 
(BmInfo* winGBmInfo, CDib* pDib) 
{ 
struct 
{ 
WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256] ; 
} logicalPalette = {0x300, 256}; 


// Get the screen DC. 
HDC Screen = ::GetDC(Q) ; 


// Copy Windows' 20 standard system colors 
// into the new logical palette. 
GetSystemPaletteEntries 
(Screen, ©, 10, logicalPalette.aEntries) ; 
GetSystemPaletteEntries 
(Screen, 246, 10, logicalPalette.aEntries + 246); 


// Get rid of the screen DC. 
::ReleaseDC(@,Screen) ; 


// Copy the standard 20 system colors into 
// the WinG bitmap's color table. 
for(int i = 0; i < 10; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i] .peRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue; 
winGBmInfo->aColors[i].rgbReserved = Q; 


logicalPalette.aEntries[i].peFlags = 0; 


(continues) 
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Listing 4.3 Continued 


winGBmInfo->aColors[i + 246].rgbRed = 
logicalPalette.aEntries[i + 246].peRed; 
winGBmInfo->aColors[i + 246].rgbGreen = 
logicalPalette.aEntries[i + 246].peGreen; 
winGBmInfo->aColors[i + 246].rgbBlue = 
logicalPalette.aEntries[i + 246] .peBlue; 
winGBmInfo->aColors[i + 246].rgbReserved = Q; 


logicalPalette.aEntries[i + 246].peFlags = 0; 
} 


// Get a pointer to the source bitmap's color table. 
LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr() ; 


// Copy the source bitmap's color table into both 
// the WinG bitmap color table and 
// into the new logical palette. 
for(i = 10; i < 246; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed = 
pColorTable[i] .rgbRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen = 
pColorTable[i] .rgbGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i] .rgbBlue; 
winGBmInfo->aColors[i].rgbReserved = Q; 
logicalPalette.aEntries[i].peFlags = 
PC_NOCOLLAPSE ; 


// Create the logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*) &logicalPalette) ; 
} 


void CWingexView: :CopyDIBToWinGTrns 
(BYTE* m_pWinGDibBits, UINT dstX, UINT dstY, 
CDib* pDib, UINT frmxX, UINT frmY, UINT frmW, UINT frmH, 
UINT trnsColor) 


// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth () ; 
DWORD srcHeight = pDib->GetDibHeight() ; 


// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr(); 


// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 

for (UINT col=0; col<frmW; ++col) 

{ 


DWORD newSrcY = srcHeight - frmH - frmyY + row; 
if (m_orientation == -1) 
newSrcyY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmX; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstxX; 
if (pDibBits[srcIndex] != trnsColor) 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 


} 


TITILTLTTTTT TT TT IIIA 
[ILILILILIL 
// END CUSTOM CODE 

[IIILIIIII IIIA 
CIIAN AINUN LEAT CAAA IA ATATA 


int CWingexView: :OnCreate(LPCREATESTRUCT lpCreateStruct) 
{ 
if (CView::0nCreate(lpCreateStruct) == -1) 
return -1; 


// TODO: Add your specialized creation code here 


TITTTTTTTTTTT TTT TTT TATA TATA TTT 
FIIIT ANTEATER A A TTA TAT 
// START CUSTOM CODE 

[ILILILILIL I TTT TTT ATTA TATA TTT 
LASATE IA TTT A ATTA TAA TTL 


// Start a Windows timer. 
SetTimer(1, 100, 0); 


TILTTTTTTT TTT TTT TTT TATA TTT TA TT TT 
[ILILILILIL TTT TTA TTT TATA TATA 
// END CUSTOM CODE 

TITILAI LLA TTT TTT TATA TATA IATC 
PRIILASTEL ATTN 


return 0; 
} 
void CWingexView: :OnDestroy () 
{ 

CView: :OnDestroy() ; 


// TODO: Add your message handler code here 


The Listings 


(continues) 
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Listing 4.3 Continued 


TILTTTTTTITTTTT TTT TTT TTT ATL 
IILIS LA AN ALELA A EEA 
// START CUSTOM CODE 

FILTTTTTTTTTT TTT TTT TTT TATA TTT 
FITTTTTTTTTTTT TTT TTT A AAEE AA 


// Destroy the Windows timer. 
KillTimer (1); 


FITTTTTTTITTTTT TTT TTT TTT ATT AT 

[IILI II IIA IIIT 

// END CUSTOM CODE 

[IILI I IIIA IITIN 

FILTITTTTTTTT TTT TTT TTT ATTA TATA 
} 


void CWingexView: :OnTimer(UINT nIDEvent) 


{ 
// TODO: Add your message handler code here and/or call default 


VIIL ETIA TTT TTT AAT TTA TTL 
LIULL TTT TTT TTT TAAL 
// START CUSTOM CODE 

AILAI IAIA TTT TTT TATA 
[IILI TTT TTT TTT TAL 


// Increment the animation frame counter. 

m_frameNum += 1; 

if (m_frameNum > 7) 
m_frameNum = 0; 


UINT x, Y; 


// Get the coordinates for the next frame. 
switch (m_frameNum) 


{ 
case 0: x = 1; y = 1; break; 
case 1: x = 163; y = 1; break; 
case 2: x = 325; y = 1; break; 
case 3: x= 1; y = 163; break; 
case 4: x = 163; y = 163; break; 
case 5: x = 325; y = 163; break; 
case 6: x = 1; y = 325; break; 
case 7: x = 163; y = 325; 

} 


// Update the WinG bitmap, by restoring the scene 

// where the last frame appeared and then 

// copying the new frame to the WinG bitmap. 

CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 70, 70, 
m_pSceneDib, 70, 70, 230, 230); 

CopyDIBToWinGTrns((BYTE*)m_pWinGDibBits, 70, 70, 
m_pPropDib, x, y, 160, 160, 255); 


// Get a device context for the window's client area. 
CDC* pClientDC = new CClientDC(this) ; 


Summary 


// Select the logical palette into the window's DC. 
SelectPalette(pClientDC->m_hDC, m_hPalette, FALSE); 


// Tell Windows to remap the system palette with 
// the program's logical palette. 
RealizePalette(pClientDC->m_hDC) ; 


// Transfer the WinG bitmap to the window's display. 
WinGBitBlt(pClientDC->m_hDC, 20, 20, WINGDIBWIDTH, 
WINGDIBHEIGHT, m_hWinGDC, 0, @); 


// Delete the window's DC. 
delete pClientDC; 


TITTAT IIIT TAT TTT ATA AT 
TIITII TTT TATA ATTA AAT L 
// END CUSTOM CODE 

[III TTT TATA TATA ATT AAT 
[IILI II IITIN 


CView::0nTimer (nIDEvent); 


Summary 


Programming a WinG application requires that you perform a number of 
steps. First, you call WinGRecommendDibFormat() to discover whether your 
WinG bitmap should be stored top-down or bottom-up in memory. Then, 
you create a BITMAPINFO structure for the WinG bitmap. You fill in this 
structure’s color table when you create an identity palette. After creating the 
palette, you call WinGCreateDC() to create a WinG device context, call 
WinGCreateBitmap() to create a WinG bitmap that’s compatible with the 
WinG DC and then select the WinG bitmap into the WinG DC. 


To draw an image on the WinG bitmap, you usually use custom drawing 
routines for speed. Then, you select the identity palette into the application 
window’s DC and transfer the WinG bitmap to the screen by calling 
WinGBitB1t(). (You can also call WinGStretchB1t(), which, unlike 
WinGBitB1t(), enables bitmap scaling.) 


When you use custom drawing routines in your WinG program, you must 
know about top-down bitmaps and bottom-up bitmaps. Most DIBs are bot- 
tom-up bitmaps, whereas a WinG bitmap can be either, depending on the 
hardware on which it’s currently running. 


But, enough studying, already! It’s time to take a look at this book’s demo 
game, Aztec Adventure. Although it’s a long way from a commercial 3 D role- 
playing game, it does give you a solid base on which to build a more sophisti- 
cated game. 
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Chapter 5 
Playing Aztec Adventure 


When I first began the programming for this book, I intended to put together 
a complete role-playing game (RPG), including many types of puzzles, story 
characters, and a wide variety of player attributes and statistics. I quickly 
discovered, however, that such a project would take much too long, and I 
had to settle for a sort of model RPG that you, the reader, could use as a basis 
for a more complete game. 


So, in its current incarnation, Aztec Adventure is more like a 3-D treasure 
hunt with role-playing characteristics than a full-fledged RPG. Still, I think 
you'll find that enhancing the game is not too difficult. (In fact, l'll give some 
enhancement suggestions in the chapters that follow.) All the basics for a 3-D 
RPG like Dungeon Master or the Eye of the Beholder series are here in Aztec 
Adventure. 


In this chapter, you'll also learn to use Dungeon Designer, which is a com- 
panion program to Aztec Adventure that lets you design your own dungeon 
layouts that can be loaded directly into the game. Using Dungeon Designer, 
you can add new dungeon floors to the game, making the quest longer and 
more difficult, or you can modify or completely replace the three dungeon 
floors included with the game. 


With all that said, it’s finally time for you to load Aztec Adventure and start 
playing. You'll find the complete game on this book’s CD-ROM, in the 
CHAPOS\AZTEC directory. Copy the AZTEC directory and all its contents to 
your hard drive. You can then start the game by double-clicking the 
AZTEC.EXE file. 
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Playing Aztec Adventure 


When you start Aztec Adventure, you see the window shown in figure 5.1. 
This window is broken up into four parts. The view window provides a first- 
person, 3-D view of your current location in the dungeon. As you move 
through the dungeon, this view continually changes, showing not only the 
current location but also objects such as treasure chests and monsters that 
you'll discover as you explore. 


Fig. 5.1 N Aztec Adventure j 
Aztec Adventure’s 
main window. 


View window 


Statistics 


Game controls 
Inventory 


The game’s controls are located immediately below the view window and are 
made up of a compass and four buttons for controlling your movement and 
viewpoint (see fig. 5.2). The compass rotates as you turn, with the larger indi- 
cator on the compass always indicating north. So, in figure 5.2, the player is 
currently facing east. 


To move forward, click on the button with the upward-pointing arrow. Alter- 
natively, you can press the up-arrow key on your keyboard. To move back- 
ward, click on the button with downward-pointing arrow, or press your 
keyboard’s down-arrow key. Finally, to turn left or right, click the left-arrow 
button or the right-arrow button, respectively. You can also use your 
keyboard’s left- and right-arrow keys to turn. 


Playing Aztec Adventure 163 


Fig. 5.2 
Compass Control buttons The game controls. 
In the top right of the game window is your character’s statistics. The statis- 
tics area includes a picture of an Aztec warrior wearing a jaguar skin and a list 
of numerical statistics. The warrior figure graphically shows exactly which 
weapon and shield you’re currently using. When you find a weapon or a 
shield, it appears on the warrior’s picture (see fig. 5.3). 
Fig. 5.3 


The warrior figure 
with a weapon and 


a shield. 

The numerical statistics show your current level (player level, not dungeon 

level), the number of experience points earned so far, the number of hit 

points you have remaining, the amount of gold you've gathered, and your 

current weapon and defense values (see fig. 5.4). The higher the level, 

weapon, and defense values, the better your character can fight and defend 

himself. Experience points control when you gain the next warrior level. For 

example, to become a level 2 warrior, you must earn 100 experience points. 

Level 3 is granted at 200 experience points, level 4 at 400, and so on. 
Fig. 5.4 
The numerical 
Statistics. 


Hit points indicate your character’s health. When your hit points fall to 0, 
your character dies and the game is over. Finally, the gold, level, and experi- 
ence statistics all work together to give you your score at the end of the game. 
The higher the score, of course, the better you did. 


Below the statistics area is your inventory. Objects you store in your inven- 
tory are keys and elixir. Keys let you get through doors, whereas elixir heals 
damage you may have received while fighting monsters. When you find a 
key or an elixir bottle, its picture appears in the appropriate inventory area 
(see fig. 5.5). 
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Fig. 5.5 
The inventory 
area. 


Fig. 5.6 

To get through 
a door, you need 
the right key. 


Exploring the Dungeon 

The goal of the game is to explore the dungeon, fighting off horrible mon- 
sters, finding all manner of treasure, and finally killing the last monster 
found on the deepest floor of the dungeon. To be successful, you must find 
the best pathway through the dungeon maze. The current version of Aztec 
Adventure includes three dungeon floors to explore, but you can add as 
many as you like, using the included Dungeon Designer program. (You learn 
more about Dungeon Designer later in this chapter.) 


When you begin the game, you start exploring by clicking the control but- 
tons (or pressing the arrow keys on your keyboard). Whenever you move or 
turn, the view window shows what you see. You can move freely about the 
dungeon, but you can’t move through walls. You also can’t move past a mon- 
ster without fighting and killing it. 


As you explore, you'll find some of the areas of the dungeon protected by 
locked doors. If you try to move through a door and it doesn’t open, you 
don’t have the right key (see fig. 5.6). 
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As you explore, it will be helpful to map the dungeon on a piece of graph 
paper. That way, you can use your map to figure out the best path through 
the dungeon in order to survive long enough to find all the treasures. Each 
dungeon floor is a 32x32 grid, with each square in the grid being either 
empty or containing one of eight different objects: 


E Wall 
Door 
Monster 
Treasure 
Key 
Weapon 


Armor 


Elixir 


The treasure, key, weapon, armor, and elixir objects all appear on the screen 
as a treasure chest (see fig. 5.7). When you step on a treasure chest, a small 
window appears and tells you what you found. 


Fig. 5.7 

Treasure chests 
contain gold, keys, 
weapons, armor, 
and elixir. 
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Fig. 5.8 

You'll have to 
fight many kinds 
of monsters. 


Fighting Monsters 

As you explore the dungeon, you stumble across many types of monsters, 
many of which you must vanquish before you move on (see fig. 5.8). Al- 
though the monsters in Aztec Adventure don’t follow you around the dun- 
geon, in many cases you can’t avoid them because they block passage to new 
areas of the dungeon floor. To fight a monster, just move toward it. When 
you do, the battle begins, with the monster lunging and defending and you 
automatically attacking with your current weapon. 


SSII A 
OEE 


Each time you strike the monster, its hit points go down. Similarly, each time 
the monster hits you, your hit points go down. If you manage to reduce the 
monster’s hit points to 0, you win the battle and the creature vanishes. How- 
ever, if your hit points fall to O anytime during a battle, your character dies 
and the game is over. 


Keep in mind that, the deeper into the dungeon you explore, the tougher the 
monsters become, so it’s important that you find elixir to keep you healthy, 
better weapons that do more damage to monsters, and shields that help de- 
fend you from attack by reducing the amount of damage you sustain from a 
hit. 


Keys 

Hidden on each dungeon floor are six keys. To open a door, you must have 
the appropriate key, so it’s important that you find all six. When you find a 
key, it appears in your inventory. The position in which the key appears indi- 
cates the key number. 
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In most cases, the key number isn’t important to you; it’s just the way the 
program matches the key to a specific door. If a door doesn’t open for you, 
you know you have to find a different key. However, key 6 is always the key 
that unlocks the entrance to the next dungeon floor. This key always appears 
in the sixth key position in your inventory. Although you may miss out on 
some treasure if you overlook other keys, you absolutely must have key 6 to 
advance to the next floor. 


You don’t need to do anything to use a key. When you come to a door, just 
move toward it. If you have the right key for that door, the door slides open 
and vanishes. If you don’t have the right key, the door stays closed, and 
you’re unable move beyond it, just as if the door were a wall. 


Using Elixir 

Your dungeon explorations will yield many types of treasure, including elixir, 
which, when used, restores a portion of your hit points. As you discover elixir 
bottles, they appear in your inventory. To use elixir, click on the elixir area of 
the inventory. A dialog box appears, asking whether you really want to use 
the elixir (see fig. 5.9). If you click Yes, the elixir heals you and disappears 
from your inventory. Otherwise, nothing happens. 


Fig. 5.9 

A dialog box asks 
whether you want 
to use elixir. 


Some elixir bottles heal more than others. When you use elixir, you always 
use the last one you found. Keep an eye on your hit points as you use elixir, 
to be sure that you healed as much as you need to. Also, be aware that you 
can never have more than 100 hit points. If you use an elixir bottle when you 
don’t need one, the elixir is wasted. Also, although you can save any elixir 
you find for later, you can never have more than six bottles simultaneously. 
If you try to pick up a treasure containing elixir when you have no room for 
another elixir, the bottle is wasted. 


Weapons and Armor 

Among the other treasures, each dungeon floor hides a weapon and a shield. 
Because these new weapons and shields are stronger than others you found 
previously, it’s important that you locate them. If you fail to equip yourself 
with better weapons and shields, you will have a tough time fighting the new 
and stronger creatures that you'll discover later in the game. 
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Fig. 5.10 

If you fail to defeat 
a monster, your 
character dies and 
the game ends. 


Fig. 5.11 

You get this 
congratulatory 
message when you 
defeat the final 
boss creature. 
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Moving to the Next Dungeon Floor 

The entrance to the next dungeon floor is always located in the current 
floor’s top right corner. To get into the final room, you must find key 6, 
which opens the final door. When the door opens, you are confronted with 
the floor’s boss creature, which you must defeat in order to advance. 


If you beat the creature, you get a congratulatory message and automatically 
move to the next floor. If you fail to beat the creature, your character dies 
and the game is over (see fig. 5.10). When you beat the boss creature on the 
third floor, you win the game (see fig. 5.11). (You can, of course, change this 
with the Dungeon Designer program. For example, if you add a fourth floor 
to the dungeon, it is the fourth floor’s boss monster you must defeat in order 
to win the game.) 


LALA SELLE 


You have. slain the 


RAMAN 
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Using Dungeon Designer 


It won’t take too long for a player to memorize the three dungeon floors that 
come with Aztec Adventure. For this reason, I put together a program called 
Dungeon Designer that lets you create your own dungeon floors. By using 
Dungeon Designer, you can create all-new games for Aztec Adventure, as well 
as modify the floors that already exist. 


In the next chapter, you build Dungeon Designer and learn how the program 
does what it does. Here, though, you get a chance to use the program. You 
can find the complete Dungeon Designer program in the CHAPOS\DUNDES 
directory on this book’s CD-ROM. To run the program, copy the entire 
DUNDES directory to your hard disk, and then double-click the DUNDES.EXE 
file. When you do, you see a window like the one shown in figure 5.12. 


Designer, FEE Fig. 5.12 
Dungeon Designer 
when it starts. 


Entrance to 
the next floor 


Dungeon grid 


Surrounding wall 


As with most Windows programs, across the top of the window is the menu 
bar and toolbar from which you can select any of the commands that control 
the program. Below the toolbar is the dungeon grid, in which you build a 
dungeon floor for Aztec Adventure. 
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Fig. 5.13 
Adding new walls 
to the dungeon 
grid. 


At first, the dungeon grid contains only a surrounding outside wall and a 
room containing an entrance to the next dungeon floor. This room hides the 
last monster the player must defeat before moving on to the next floor. Be- 
cause defeating this monster is the action that triggers Aztec Adventure to 
load the next floor, you must always have a monster at this location in the 
grid. You can, however, change the default monster by deleting the one 
that’s there and creating a new monster for the final room. 


Also, although you can place or delete any walls of your own, you cannot 
delete any of the default walls, which include the surrounding wall and the 
wall that defines the entrance to the next floor. Without these walls, Aztec 
Adventure would not run properly. 


Building a Dungeon Floor 

To build a dungeon floor, you select items from the Items menu or from the 
toolbar, and then click in the dungeon grid to place the selected item. For 
example, to place walls in the dungeon grid, first click the W item in the 
toolbar (or select Wall from the Items menu). Then click on a square in the 
dungeon grid. The square changes to gray, indicating that there is now a wall 
there. As long as the Wall tool is selected, you can place as many walls as you 
like—just keep clicking squares on the grid (see fig. 5.13). 


Selected item 


New walls 
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To remove an item from the dungeon grid, just click it. The item vanishes 
from the grid, leaving its square blank. You must delete an item from a 
square before you can place another item in it. For example, if you decide 
that you want to place a monster in a grid square currently holding a wall, 
first click the square to remove the wall. Then select the Monster item and 
click the same square again. 


Item Numbers and Values 

Placing walls in the dungeon grid is easy; you just select the Wall item and 
click squares in the dungeon grid. However, placing other items—such as 
monsters, doors, and keys—is not quite as simple. For every type of item you 
place in the dungeon, you must define an item number and usually an item 
value, as well. For example, if, at this point, you were to select the Monster 
tool and click on the grid, you’d see the dialog box shown in figure 5.14. 


Fig. 5.14 
The Item dialog 
box. 


The Item dialog box lets you define values for the item you’re currently try- 
ing to place in the dungeon grid. The Item Number is the value that identifies 
this item. For example, you can have up to three different types of monsters 
on each dungeon floor. These different types are numbered 0, 1, and 2. So, 
for a Monster, the Item Number field in the Item dialog box must be 0, 1, 

or 2. 


The meaning of the Item Value field varies from item to item. For a Monster, 
Item Value is the number of hit points the monster has, which, of course, 
determines how difficult the monster is to defeat. (The monster’s attack 
strength is based on the monster’s number and the floor on which it ap- 
pears.) For a treasure, the Item Value is the number of gold pieces contained 
in the treasure chest. For a Wall, Door, or Key, the Item Value field has no 
meaning at all. For easy reference, table 5.1 lists each dungeon item and the 
meaning of its Item Value field. 
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Fig. 5.15 
Creating a new 
item type. 


Table 5.1 Item Value Descriptions 


item Item Value Meaning 
a 

Wall None 

Door None 

Monster Monster’s hit points 

Treasure Number of gold pieces in the chest 

Key None 

Sword The amount of damage done by the weapon 

Armor The number of hit points of protection 

Potion The number of hit points of healing 


E EE ES 


The first time you place an item type in the grid (for example, Monster 0), 
you must fill in both the Item Number and Item Value fields. When you do, 
Dungeon Designer asks whether you want to create a new item (see fig. 5.15). 
Click the Yes button to create a new type of the selected item. Click No to 
cancel the command. If you click Yes, Dungeon Designer adds the new item 
type to its item database, as well as places the item in the selected dungeon 
grid square. 


The next time you want to place that item type in the dungeon, you need 
only fill in the Item Number. Dungeon Designer automatically searches 
through its item database and matches the item with its Item Value. In fact, 
even if you type a new Item Value, Dungeon Designer ignores it and uses the 
previously defined value. 


In addition to their item-value meanings, there’s a limit to the number of 

certain item types you can place in each dungeon layout. For example, you 
must not define more than three monster types for each dungeon floor you 
design. Table 5.2 lists the limits for all items you can place in the dungeon. 


Using Dungeon Designer 


Table 5.2 The Maximum Number of Each Item Type per Floor 


Item Item Value Meaning 
Wall N/A 

Door 6 (numbered 0 to 5) 
Monster 3 (numbered 0 to 2) 
Treasure No limit 

Key 6 (numbered 0 to 5) 
Sword 1 (numbered 0) 

Armor 1 (numbered 0) 


Potion (elixir) No limit 


You may be confused about the difference between an item type and an actual item 
placed in a dungeon. Take monsters as an example. Although you can define only 
three monster types, you can place as many monsters of each type as you like on the 
dungeon grid. For example, if you define Monster 0 to have 5 hit points, Monster 1 
to have 10 hit points, and Monster 2 to have 20 hit points, you cannot define any 
more monster types. However, you can place as many Monster Os, Monster 1s, and 
Monster 2s as you like in the dungeon layout. Fill the entire dungeon with them, if 
you like! 


Keys and Doors 

Doors and keys have no meaningful item value; they use only the item num- 
ber. Still, you need a way to match keys up with the doors that they open. 
This is a lot simpler than you might suspect. Key number 0 opens all doors 
with an item number of 0, key number 1 opens all doors with an item num- 
ber of 1, and so on. But, remember that you can have only six key and door 
types, numbered 0 through 5. You don’t have to use all six types in a dun- 
geon layout, but you must never define more than six. 


Viewing Items in the Dungeon 

As you place more and more items on the dungeon grid, you may forget what 
each of the items actually is. Although all monsters are red, all keys are yel- 
low, all doors are blue, and so on, there’s no way to tell from the dungeon 
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Tip 

As you design your 
dungeon layouts, 
keep a list of the 
item types you’ve 
defined, along with 
their item values. 
That way, you can 
easily refer to what 
you’ve done so far. 
Such a list also 
makes it easier to 
pick which item 
types you'd like to 
place in specific 
locations in the 
dungeon grid. 
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Fig. 5.16 
Getting informa- 
tion about an 
item. 


grid the types (item numbers) of any items placed there. For example, al- 
though you may have defined three types of monsters for your dungeon 
layout, all three types appear as red squares on the grid. 


Luckily, Dungeon Designer provides a way for you to see the item number 
and item value of any item placed in the grid. Simply right-click any item, 
and a dialog box appears, displaying information about the item (see fig. 
5.16). Click the OK button or press Enter to dismiss the dialog box. 


Printing a Dungeon Layout 

Once you've got a dungeon design put together, you can print it for future 
reference. Dungeon Designer’s File menu contains three print-related com- 
mands—Print, Print Preview, and Print Setup—that help you create hard 
copies of your dungeon designs. 


Choose the Print Preview command when you want to see, before you do the 
actual printing, what the printed dungeon will look like. When you select 
this command, Dungeon Designer displays a window like that shown in 
figure 5.17. This represents the page that your printer will produce when you 
actually print the dungeon. Of course, unless you have a color printer, the 
results will be black and white. 


Across the top of the print preview window is a toolbar that lets you zoom in 
and out on the view, as well as print the dungeon and close the print preview 
window. Unfortunately, due to the size of Dungeon Designer’s main window, 
all of the print preview window’s toolbar buttons don’t fit. To see all the 
buttons, you can expand the size of the window by dragging its left or right 
border (see fig. 5.18). 


To print the dungeon, select the File menu’s Print command or select the 
Print button on the toolbar. If you need to change your printer setup first, 
select the File menu’s Print Setup command. 
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Fig. 5.17 
The print preview 
window. 


Level01_.dun - Dungeon Designer 


Fig. 5.18 
The resized print 
preview window. 
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Loading and Saving Dungeon Files 

After you’ve created a dungeon layout, you’ll want to try it out with Aztec 
Adventure. When you do, you’ll undoubtedly find that you need to fine tune 
a thing or two. To do this, simply load the dungeon floor back into Dungeon 
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Tip 

Dungeon Designer 
remembers the 
names of the last 
four files loaded 
into the program. 
You can reload one 
of these files sim- 
ply by clicking its 
name at the bot- 
tom of the File 
menu. 


Fig. 5.19 
The PANEL.BMP 
file. 
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Designer, make whatever changes you need, and save the file again. The File 
menu’s Open command handles the dungeon-loading task. You can also load 
a dungeon floor by clicking the Open button on the toolbar. 


Of course, once you’ve created or modified a dungeon floor, you must save it 
to disk. The File menu’s Save and Save As commands handle this task. You 
can also click on the Save button in the toolbar. When you save a dungeon, 
you can give the file any name you like. However, the Aztec Adventure pro- 
gram expects to find dungeon files with specific names. The first floor must 
be named LEVELO1.DUN, the second must be named LEVELO2.DUN, and so 
on. 


Data Files Used by Aztec Adventure 


In order to run properly, Aztec Adventure expects to find certain data and 
graphics files in the same directory as the game program. Three files that 
every Aztec Adventure game must have are PANEL.BMP, SUNDRY.BMP, and 
MESSAGE.BMP, shown in figures 5.19, 5.20, and 5.21. The PANEL.BMP file 
contains the bitmap used for the main screen, whereas the SUNDRY.BMP file 
contains the smaller items that the program needs to display throughout the 
game. The MESSAGE.BMP file contains the message boxes that pop up when 
you open a treasure chest. If you have artistic ability, you can modify the 
graphics in these files, as long as you don’t change the size or position of any 
of the items. 


Data Files Used by Aztec Adventure 177 


Fig. 5.20 
The SUNDRY.BMP 
file. 


You have slain a 


Fig. 5.21 

The 
MESSAGE.BMP 
file. 


Aztec Adventure also needs at least one dungeon-floor file named 
LEVELO1.DUN. You can have as many dungeon floors as you like (up to 99), 
but you must name them consecutively—LEVELO2.DUN, LEVELO3.DUN, and 
so on—as described previously in this chapter. These files are created or 
modified with the Dungeon Designer program. 
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Fig. 5.22 
The LEVELO1A.BMP 
file. 


For each dungeon floor, you must have a number of other files. These include 
the bitmap files containing the pieces from which the 3-D dungeon scene is 
created, as well as three sets of monster graphics. For example, if you have a 
dungeon-floor file named LEVELO1.DUN (required), you must also have the 
files LEVELO1A.BMP, LEVELO1B.BMP, MONSTO1A.BMP, MONSTO1B.BMP, 
and MONSTO1C.BMP. Similarly, if you have LEVELO2.DUN, you must have 
LEVELO2A.BMP, LEVELO2B.BMP, MONSTO2A.BMP, MONSTO2B.BMP, and 
MONST02C.BMP. 


In the version of Aztec Adventure included with this book, the 
LEVELO1A.BMP file looks like figure 5.22. As you can see, this file contains 
the walls, floor, and doors needed to construct a 3-D view of the first floor of 
the dungeon. The images needed for the treasure chest are also included in 
this file. Finally, because this first floor is an outdoor scene, four extra images 
depict what the player sees on the horizon in each of the four directions he 
can look. 


The LEVELO1B.BMP file is very similar to LEVELO1A.BMP as far as the layout 
of the images goes (see fig. 5.23). But, if you look closely, you'll notice that 
the wall and floor images are subtly different from those in LEVELO1A.BMP. 
As you'll see when you build the Aztec Adventure program in upcoming 
chapters, the differences in these graphics give the player the illusion of 
movement each time the player steps forward or backward in the dungeon. 
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Fig. 5.23 

The 
LEVELO1B.BMP 
file. 


The MONSTO1A.BMP, MONSTO1B.BMP, and MONSTO1C.BMP files contain 
the graphics for each of the three types of monsters defined for floor 1 of the 
dungeon. Likewise, the files MONSTO2A.BMP, MONSTO2B.BMP, and 
MONST02C.BMP contain graphics for the monsters on floor 2 of the dun- 
geon. Figure 5.24 shows what a typical monster file looks like. 


Fig. 5.24 

The 
MONST02C.BMP 
file. 
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Fig. 5.25 

The 
MONSTER.BMP 
file. 


Starting at the top of the bitmap, the first image is the image the player sees 
when he’s standing right in front of the creature. The second and third im- 
ages come into play when the player is fighting the monster. When waiting 
between attacks, the images switch between the first and the second images 
in the top row. The third image in that row is the monster lunging toward 
the player. 


In the next row, the first image is what the player sees when he attacks the 
monster, whereas the second and third images make up the animation frames 
that dissolve the creature when it dies. The third row of images provides 
views of the creature from a distance of two and three squares away. 


If you’re artistically inclined (or know someone who is), you can create your 
own monster files by using the MONSTER.BMP file as a guide for image place- 
ment (see fig. 5.25). As long as you keep your creature’s images within the 
guide lines and you remember to change the background colors to the trans- 
parent color (palette index 253), Aztec Adventure should have no difficulty 
displaying them. (In the lower right of MONSTER.BMP is a rectangle contain- 
ing the transparent color you should use to fill the monsters’ background 
areas. If you don’t understand how the transparent color is used, look at the 
MONSTO01A.BMP file.) You'll find the MONSTER.BMP file in the CHAPOS 
directory on this book’s CD-ROM. 


Data Files Used by Aztec Adventure 


To sum up how all these graphics and data files work together, table 5.3 lists 
all the files used with the version of Aztec Adventure included with this book. 


Table 5.3 Files Used with Aztec Adventure 


File Name 
AZTEC.EXE 
LEVELO1.DUN 
LEVELO2.DUN 
LEVELO3.DUN 
PANEL.BMP 
SUNDRY.BMP 
MESSAGE.BMP 
LEVELO1A.BMP 
LEVELO1B.BMP 
LEVELO2A.BMP 
LEVELO2B.BMP 
LEVELO3A.BMP 
LEVELO3B.BMP 
MONST01A.BMP 
MONST01B.BMP 
MONST01C.BMP 
MONST0O2A.BMP 
MONST02B.BMP 
MONST02C.BMP 
MONST03A.BMP 
MONST03B.BMP 


MONST03C.BMP 


Description 


The game program 


Floor 1, Dungeon Designer data file 


Floor 2, Dungeon Designer data file 
Floor 3, Dungeon Designer data file 


Bitmap for main window display 


Images needed to update main display 


Message images for treasure chests 


Images for building the 3-D view for floor 1 


Images for building the 3-D view for floor 1 
Images for building the 3-D view for floor 2 


Images for building the 3-D view for floor 2 


Images for building the 3-D view for floor 3 


Images for building the 3-D view for floor 3 


Images for monster 0 on floor 1 


Images for monster 1 on floor 1 


Images for monster 2 on floor 1 


Images for monster 0 on floor 2 


Images for monster 1 on floor 2 


Images for monster 2 on floor 2 


Images for monster 0 on floor 3 


Images for monster 1 on floor 3 


Images for monster 2 on floor 3 
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Fig. 5.26 
The PALETTE.BMP 
file. 


A Word on Color 

When designing your own graphics, you must remain conscious of the effects 
caused by changing colors in the palette. In Aztec Adventure, the 256 colors 
in the palette are divided into sections that represent the colors for different 
parts of the game. Figure 5.26 shows the file PALETTE.BMP that’s included on 
this book’s CD-ROM, in the CHAPOS directory. This graphics file shows how 
the various colors are used in Aztec Adventure. 


MASTER DUNGEON PALETTE 


As you can see in the figure, the first and last 10 colors in the palette make up 
Windows’ system colors. You can use these colors in your graphics, but you 
must not change any of them. If you do, any changes you make will get 
wiped out by the Aztec Adventure program, which will automatically restore 
the system colors into these 20 palette entries. 


Fifteen colors—indexes 10 through 24 in the palette—are used to display the 
main panel bitmap. You can use these colors, but you must not change them. 


Colors 25 through 31 are extra colors with which you can do whatever you 
want. Colors 32 through 95 are used for the images that represent the floor, 
walls, and doors of the current dungeon floor. These colors, along with colors 
96 through 127, change when a new level is loaded. If you create your own 
graphics, you can change these colors for each level. The same is true of col- 
ors 128 through 245, which are the colors used for each floor’s monsters. 


Aztec Adventure gets its colors from the palette associated with the 
LEVELxxA.BMP, where xx represents the floor number. For example, for 
floor 1, Aztec Adventure loads the palette from the file LEVELO1A.BMP. 
When the player moves to floor 2, Aztec Adventure uses the palette found 
with LEVELO2A.BMP. The palettes in these files, and subsequent files for 
succeeding floors, should be set up according to figure 5.26. 


Summary 


Summary 


Aztec Adventure may not be a full-fledged role-playing game, but it does 
show you how such games work. After you learn, in upcoming chapters, how 
to program the game, you should be able to build on Aztec Adventure to 
create a more sophisticated adventure. 


Dungeon Designer helps you build new games by providing a means for 
creating the data files that define the contents of each dungeon floor. In 
addition, in order to create your own dungeons, you can modify the graphics 
files included with Aztec Adventure. However, you must not move or change 
the size of any images in these files, and you must be sure to set up your pal- 
ettes properly. 


In the next chapter, you get back to programming by using Visual C++ to 
build the Dungeon Designer application. 
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Chapter 6 
Programming Dur 
Designer 


In the last chapter, you got a chance to play Aztec Adventure, as well as to 
use Dungeon Designer to create and modify dungeon-floor layouts. Now that 
you’re familiar with these programs, you'll learn to build the Dungeon De- 
signer program using Visual C++. As you do, you'll discover how the program 
code works. 


Although Dungeon Designer is a complete dungeon construction program for 
Aztec Adventure, you may find ways to make the program work better or to 
add new types of items to the dungeon grid. You’re encouraged to make such 
modifications. For example, you could add a trick-wall item that the player 
can walk through. Or, you could add different types of potions, rather than 
having just the one included with Dungeon Designer as it stands now. (Of 
course, if you add items to the editor, you also have to modify the game pro- 
gram so that it can handle those new items.) Obviously, the more powerful 
that Dungeon Designer becomes, the more sophisticated your Aztec Adven- 
ture games can be. 


Creating Dungeon Designer, 
Version 1 


To keep the process as understandable as possible, you’ll build Dungeon 
Designer a step at a time. In each version of the program that follows, you'll 
add another section of code, until you’ve finally completed the Dungeon 
Designer program. In this section, you create the basic AppWizard applica- 
tion on which the final Dungeon Designer program is based. 
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1. Use AppWizard to create the basic files for the Dungeon Designer pro- 
gram, selecting the options listed in the following table. When you’re 
done, the New Project Information dialog box will appear; it should 


look like figure 6.1. 


Dialog Box Name 


New Project 


Step 1 
Step 2 of 6 
Step 3 of 6 


Step 4 of 6 


Step 5 of 6 


Options to Select 

Name the project DUNDES and set the 
project path to C:\MSVC20. Leave other 
options set to their defaults. 

Select Single Document. 

Leave set to defaults. 

Leave set to defaults. 

Turn off all application features except 
Dockable Toolbar, Printing and Print 


Preview, and Use 3D Controls. 


Leave set to defaults. 


Step 6 of 6 


Leave set to defaults. 


Fig. 6.1 
The options for 
the basic DUNDES i 
" g |F Application type of dundes: 
application. Single Document Interface Application targeting: 


Classes to be created: 
Appl t 


CDundesApp in dundes.h and dundes,cpp 
Frame: CMainFrame in mainfrm.h and mainfrm.cpp 
Document: CDundesDoc in dundedas.h and dundedoc.cpp 
View: CDundesView in dundevw.h and dundevw.cpp 


Features: 


+MSVC Compatible project file (dundes. mak) 


+ Initial toolbar in main frame 


+ Printing and Print Preview support in view 


+ 3D Controls 


+ Uses shared DLL implementation (MFC30.DLL) 


+ Localizable text in U.S. English 
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2. Double-click DUNDES.RC in the project window. The resource browser 
window appears, as shown in figure 6.2. 


i = dundes.tc 


3. Double-click the Bitmap resource, and then double-click the 
IDR_MAINFRAME resource ID. You see the bitmap editor, as shown 
in figure 6.3. 


d= Microsoft Visual C++ - dundes.mak 


dundes.tc - IDR_MAINFRAME 
oma 


4. Using the bitmap editor’s tools, make the application’s toolbar 
bitmap look like figure 6.4. If you prefer, you can simply copy the 
TOOLBAR.BMP file from this book’s CD-ROM to your project’s RES 
directory. You'll find TOOLBAR.BMP in the CHAPO6\DUNDES\RES 
directory. 


Fig. 6.2 
The resource 
browser window. 


Fig. 6.3 
The bitmap editor. 
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Fig. 6.4 
Dungeon 
Designer’s toolbar 
bitmap. 
5. Close the bitmap editor and open the menu editor. Change the name of 
the Edit menu to &Items, and delete all items from the menu. 
6. Add the following menu commands to the Items menu, using the indi- 
cated IDs. The resulting menu is shown in figure 6.5. 
Command ID 
Wall ID_ITEMS_WALL 
&Door ID_ITEMS_DOOR 
&Monster ID_ITEMS_MONSTER 
&Treasure ID_ITEMS_TREASURE 
&Key ID_ITEMS_KEY 
&Sword ID_ITEMS_SWORD 
&Armor ID_ITEMS_ARMOR 
&Potion ID_ITEMS_POTION 
Fig. 6.5 <a dundes.rc - IDR_ MAINFRAME (Menu) 
Dungeon 
Designer’s Items 
menu. 


7. Change the command in the Help menu to &About Dungeon 
Designer..., as shown in figure 6.6. 


8. Close the menu editor and open the accelerator editor for the 
IDR_MAINFRAME accelerator table. Delete all accelerators except 
ID_FILE_NEW, ID_FILE_OPEN, ID_FILE_PRINT, and ID FILE SAVE, as 
shown in figure 6.7. 
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f = dundes 1c - IDR_ MAINE RAME (Menu) 2 E ; 5i if z Fig. 6.6 
(Bie ems View: Hise) gemm Dungeon 
fea Designer’s Help 
menu. 
Fig. 6.7 
i Dungeon 
f ID_FILE_NEW age 
ID_FILE_OPEN Designer’s 


ID_FILE_PRINT 


accelerator table. 


9. Close the accelerator editor and open the icon editor for the 
IDR_MAINFRAME icon. Modify the icon for the application. Or, if you 
like, just use Import, Cut, and Paste to copy the DUNDES.ICO file 
from this book’s CD-ROM (see fig. 6.8). You’ll find the icon in the 
CHAP06\DUNDES\RES directory. 


E dundes-rc - IDR_MAINFRAME {con j | Fig. 6.8 
Editing Dungeon 
Designer’s icon. 


10. Change the About dialog box to look like figure 6.9, adding and chang- 
ing static text, as well as changing the dialog box’s title. 
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Fig. 6.9 fa “ABC (Dialog) 

Editing Dungeon : ; 

Designer’s About 

dialog box. 

11. Close the dialog box editor and open the string table editor. Change 

the first segment of the IDR_MAINFRAME string to Dungeon Designer (see 
fig. 6.10). 

Fig. 6.10 [I dundes.rc 

Changing Ree 

Dungeon APX | 7344 | dundes 

Designer’s | DERE 5760 Ca a ra cocoa 

string table. | Open an existing document\nOpen 


Close the active document\nClose 


ID_FILE Save the active document\nSave 
ID_FILE_SAVE_AS Save the active document with a new name\nSave As 


ID_FILE_PAGE_SETUP Change the printing options\nPage Setup 


ID_FILE. 
ID_FILE_PRINT Print the active document\nPrint 
ID_FILE_ PRINT PREVIEW _ 


PRINT_SETUP Change the printer and printing options\nPrint Setup 


12. Close the resource browser window and then load the MAINFRM.CPP 
file. Replace the toolbar button IDs near the top of the file with the 
following: 


static UINT BASED_CODE buttons[] = 
{ 
// same order as in the bitmap 'toolbar.bmp' 
ID_FILE_NEW, 
ID_FILE_OPEN, 
ID_FILE_SAVE, 
ID_FILE_PRINT, 
ID_SEPARATOR, 
ID_ITEMS WALL, 
ID_ITEMS_ DOOR, 
ID_ITEMS_ MONSTER, 
ID_ITEMS_TREASURE , 
ID_ITEMS_KEY, 
ID_ITEMS_SWORD, 
ID_ITEMS_ARMOR, 
ID_ITEMS_POTION, 
ID_SEPARATOR, 
ID_APP_ABOUT, 
}; 
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This list tells the program which command IDs are associated with 
which toolbar buttons. The IDs are listed in the same order as the 
matching buttons. 


Running Dungeon Designer, Version 1 

You’ve now created the basic Dungeon Designer application, as well as modi- 
fied its user interface. To compile the program, select the Project menu’s 
Rebuild All command. Visual C++ then compiles and links the application. 
When it’s finished, you can run Dungeon Designer by selecting the Project 
menu’s Execute command. When you do, you see the window shown in 
figure 6.11. 


agx Fig. 6.11 
Dungeon Designer, 


| daug N S S a Bi Version 1. 


The first thing you'll notice is that all of the commands in the Items menu, as 
well as their counterparts on the toolbar, are grayed out. This is because you 
have not yet written functions to handle these commands. All the other com- 
mands work, though. 


For example, selecting the File menu’s Open command (or clicking the 
toolbar’s Open icon) brings up the Open dialog box (see fig. 6.12), from 
which you can select a file. If you select a file, although the application can- 
not yet actually load data, Dungeon Designer’s title bar shows the name of 
the file. Selecting the File menu’s New command (or clicking the New icon 
on the toolbar) returns the file title to Untitled. The Save and Save As com- 
mands work, too, causing the application to display the Save As dialog box. 
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Fig. 6.12 
The Open dialog 
box. 


Fig. 6.13 
The Print dialog 
box. 


Believe it or not, even the Print, Print Preview, and Print Setup commands 
work, although all you can print at this point is a blank page. When you 
choose the File menu’s Print command (or click the toolbar’s Print icon), for 
example, the Print dialog box appears (see fig. 6.13). When you choose the 
File menu’s Print Preview command, the print preview window appears, 
showing a blank document (see fig. 6.14). Finally, choosing the File menu’s 
Print Setup command brings up the Print Setup dialog box (see fig. 6.15). 


And, still, thanks to AppWizard, your basic Dungeon Designer program does 
more! On the View menu, you can turn the toolbar on and off by selecting 
the Toolbar command. You can even drag the toolbar from the top of the 
window and make a toolbox from it (see fig. 6.16). Finally, to see the 
program’s About dialog box (see fig. 6.17), select the Help menu’s About 
Dungeon Designer command, or click on the toolbar’s Help button. 
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f = Untitled - Dungeon D Fig. 6.14 
The print preview 
window. 
—— n Fig. 6.15 
Print Setup The Print Setup 
i 1S Se E eee dialog box. 
4 ta Default printer: Ready 
a. 
Lete 8%x11in 
Fig. 6.16 


Making a toolbox 
from Dungeon 
Designer’s toolbar. 


Becerro 
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Fig. 6.17 —— ae Ps — 
Dungeon... aw&§$§$C ES ee | 
Designer’s About fc a] | | | e 

dialog box. | 
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Creating Dungeon Designer, 
Version 2 


Version 1 of Dungeon Designer has a complete menu bar and toolbar, but the 
commands on the Items menu, as well as their counterparts on the toolbar, 
are not yet activated. Instead, when you run Dungeon Designer, these com- 
mands are grayed out. This is because you have not yet written the code that 
will handle these commands when the user selects them. In this section, 

you add the functions and data items you need to activate all the menu 
commands. 


The complete source code and executable file for this step in the creation of the 
Dungeon Designer application is in the CHAPO6\DUNDES2 directory of this book’s 
CD-ROM. 


1. Load DUNDES.H and add the following lines to the top of the file, right 

after the #include "resource.h" // main symbols line: 
enum {Empty, Wall, Door, Key, Monster, 
Treasure, Sword, Armor, Potion }; 

This enumeration defines the various editing modes that are controlled 
by the commands in the Items menu. For example, if you select the 
Wall command in the Items menu, Dungeon Designer will be in the 
Wall editing mode. 
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2. Load the DUNDEVW.H file and place the following in the class 
declaration’s Attributes section, right after the CDundesDoc* 
GetDocument () line: 

protected: 
int m_mode; 
The preceding lines declare m_mode, which stores the current editing 
mode, as a data member of the CDundesvView class. 


3. Load the DUNDEVW.CPP file and add the following line to the class’s 
constructor, right after the // TODO: add construction code here 
comment: 


m_mode = Wall; 
This line ensures that the program begins in the Wall editing mode. 


4. Use ClassWizard to add COMMAND and UPDATE_COMMAND_UI functions for all 
the commands in the Items menu, as shown in figure 6.18. 


Functions created for COMMAND messages respond to menu commands. 
For example, if the user selects the Item menu’s Wall command, the 
COMMAND function OnItemsWall() is called. Functions created for 
UPDATE_COMMAND_UI messages control the appearance of menu com- 
mands. In Dungeon Designer, for example, the UPDATE_COMMAND_UI func- 
tion OnUpdateItemsWall() determines whether the Wall menu command 
is checkmarked. 
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5. Add the following lines to each of the OnUpdateItems functions, replac- 
ing XXXX with the appropriate mode. For example, in the 
OnUpdateItemsTreasure() function, you change XXXX to Treasure. Place 
the lines immediately following the // TODO: Add your command update 
UI handler code here comment: 

if (m_mode == XXXX) 
pCmdUI ->SetCheck (TRUE); 


else 
pCmdUI ->SetCheck (FALSE) ; 


The preceding lines display or remove a menu checkmark, depending 
on the current editing mode. For example, if the current editing mode 
is Wall, the OnUpdateItemsWal1() function turns on the checkmark next 
to the Item menu’s Wall command. The other OnUpdateItems functions 
then turn off check marks for all other commands in the Items menu. 
The checkmarked item also determines which button on the toolbar is 
pressed. 


6. In the OnItems functions, add the following line, replacing the xxxx with 
the appropriate mode. For example, in OnItemsTreasure(), you’d replace 
XXXX With Treasure. Place the line immediately after the // TODO: Add 
your command handler code here comment: 


m_mode = XXXX; 


The preceding line changes the current editing mode whenever the user 
selects a command from the Items menu. For example, if the user se- 
lects the Item menu’s Sword command, the OnItemsSword() function 
executes the line m_mode = Sword, which sets the editing mode to Sword. 


This completes version 2 of Dungeon Designer. To compile the program, 
select the Project menu’s Build command. Visual C++ then compiles and 
links the application. 


Running Dungeon Designer, Version 2 

When you run the new version of Dungeon Designer, you see the screen 
shown in figure 6.19. As you can see, the toolbar is now fully working, as are 
all the commands in the menus. When you click one of the item buttons on 
the toolbar, the button stays pressed, and the program switches to the new 
mode. You can also select the editing mode from the Items menu, where the 
currently active mode has a checkmark next to its name. 
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| Untitled - Dungeon Designer — BER] Fig. 6.19 

aon Dungeon Designer 
with working 
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toolbar. 


The code you just added to this version of the program is fully explained in 
the preceding steps. If you’re still unsure of what the program is doing, you 
should reread the text that explains the lines that you added to the program. 
Once you're confident of your understanding, move to the next section of 
this chapter, where you create the next version of the program. 
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Just being able to select editing modes doesn’t do you much good, since you 
still can’t create a dungeon with the items you select. In order to create a 
dungeon, you first need a way to draw the dungeon grid on the screen and to 
redraw the grid whenever the window needs repainting. In this section, you'll 
add the functions needed to accomplish these tasks. 


The complete source code and executable file for this step in the creation of the 
Dungeon Designer application can be found in the CHAPO6\DUNDES3 directory of 
this book’s CD-ROM. 


1. Use ClassWizard to add the PreCreateWindow() function to 
MAINFRM.CPP, as shown in figure 6.20. 
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Fig. 6.20 
Adding 
PreCreateWindow() 
to MAINFRM.CPP. 


2. 


| < MFC ClassWizard 


Add the following code to the PreCreateWindow() function, right after 
the // TODO: Add your specialized code here and/or call the base 
class comment: 


cs.cx 
cs.cy 


402; 
470; 


These lines set the width and height of the program’s main window. 


Load DUNDEVW.H and add the following to the Attributes section, 
right after the line int m_mode that you placed there previously: 


CBitmap* m_pBitmap; 


This line declares m_pBitmap, which is a pointer to a CBitmap object, as a 
data member of the CDundesView class. 


Also in DUNDEVW.H, add the following function declaration to 
CDundesView’s Implementation section, right after the first protected 
keyword: 


void DrawGrid(CDC* dc); 


This line declares DrawGrid() as a member function of the CDundesView 
class. As you'll see, DrawGrid() draws the dungeon grid lines on the 
screen. 


Load DUNDES.H and place the following lines near the top of the file, 
right after the enumeration you placed there previously: 


7. 
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const SQUARESIZE = 12; 
const ROWSIZE = 32; 
const COLSIZE = 32; 
const OFFSET = 2; 


These lines define constants for some frequently used values in the 
program. SQUARESIZE is the size in pixels of each square in the dungeon 
grid, ROWSIZE is the number of rows in the grid, COLSIZE is the number 
of columns in the grid, and OFFSET is the number of pixels from the top 
and left that the grid is positioned in the main window. 


Use ClassWizard to add the OnCreate() function (WM_CREATE message) to 
the CDundesView class (see fig. 6.21). 


|. MFC ClassWizard Fig. 6.21 
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Add the following code to OnCreate(), right after the // TODO: Add your 
specialized creation code here comment: 


// Get a device context for the window. 
CClientDC clientDC(this) ; 


// Create a bitmap compatible with the window DC. 
m_pBitmap = new CBitmap; 
m_pBitmap ->CreateCompatibleBitmap(&clientDC, 640, 480); 


// Create a memory DC compatible with the window DC. 
CDC memDC; 
memDC.CreateCompatibleDC(&clientDC) ; 


// Select the bitmap into the memory DC. 
memDC.SelectObject(m_pBitmap) ; 


// Clear the memory DC to white. 
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CBrush* brush = new CBrush(RGB(255, 255,255) ) ; 
memDC.FillRect(CRect(®, ©, 639, 479), brush); 
delete brush; 


// Draw the dungeon grid on the memory bitmap. 
DrawGrid(&memDC) ; 


The OnCreate() function is called when the program receives the 
WM_CREATE message, which Windows sends when the view window is 
about to be created. You’ll look at this function in detail later in this 
chapter. 


8. Add the following function to the end of DUNDEVW.CPP: 


void CDundesView: :DrawGrid(CDC* dc) 


{ 
// Draw the grid's vertical lines. 
for (int x=; x<=COLSIZE; ++x) 
{ 
dc ->MoveTo(SQUARESIZE*x+OFFSET, OFFSET); 
dc ->LineTo(SQUARESIZE*x+OFFSET, 
SQUARESIZE*COLSIZE+OFFSET) ; 
} 
// Draw the grid's horizontal lines. 
for (int y=0; y<=ROWSIZE; ++y) 
{ 
dc->MoveTo(OFFSET, SQUARESIZE*y+OFFSET) ; 
dc ->LineTo (SQUARESIZE*ROWSIZE+OFFSET, 
SQUARESIZE*y+OFFSET) ; 
} 
} 


This function simply draws the lines that form the dungeon grid. The 
first for loop takes care of the vertical lines, whereas the second for 
loop draws the horizontal lines. The pointer dc indicates the device 
context on which the lines should be drawn. 


9. Add the following line to the CDundesView class’s destructor: 
delete m_pBitmap; 


This line deletes the bitmap that is created in the OnCreate() function. 


10. Add the following lines to the CDundesView class’s OnDraw() function, 
right after the // TODO: add draw code for native data here comment: 


// Create a memory DC that's compatible 
// with the paint DC. 

CDC memDC; 
memDC.CreateCompatibleDC(pDC) ; 
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// Select the bitmap into the memory DC. 
memDC.SelectObject (m_pBitmap) ; 


// Blit the bitmap onto the screen. 

pDC->BitB1t(@, ©, 640, 480, &memDC, ©, @, SRCCOPY); 
The preceding lines copy the bitmap in memory to the screen whenever 
the main window needs to be redrawn. You’ll see how the OnDraw() 
function works later in this chapter. 


This completes version 3 of Dungeon Designer. To compile the program, 
select the Project menu’s Build command. Visual C++ then compiles and 
links the application. 


Running Dungeon Designer, Version 3 

When you run the new version of Dungeon Designer, you see the screen 

shown in figure 6.22. Now, the program not only has fully working menus, 

but also a dungeon grid into which you can place the items that make up a 

dungeon floor. The main window is even perfectly sized to contain the dun- 

geon grid. If you minimize Dungeon Designer or cover it with another win- 

dow, the grid is instantly redrawn when you reactivate the program, thanks 

to the bitmap that holds the image for the window. In the sections that fol- 

low, you'll see how this drawing mechanism works. 

Fig. 6.22 
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Examining the OnCreate() Function 

As you learned in Chapter 4, “Programming with WinG,” in a Windows ap- 
plication, whenever a new window is created, Windows sends the application 
a WM_CREATE message. Because the window has a valid handle when WM_CREATE 
is sent, the function OnCreate() (which responds to the WM_CREATE message in 
an MFC program) is a good place to do initialization that requires a valid 
window. In Dungeon Designer, the program uses OnCreate() to set up the 
bitmap that holds the window’s display. 


In order to update Dungeon Designer’s window as quickly as possible when it 
needs to be redrawn, the program stores a copy of the window’s image in a 
bitmap in memory. In order to be able to display this bitmap in the window’s 
client area, it must be selected into a device context that’s compatible with 
the window’s device context. So, the first task in OnCreate() is to create a 
CClientDCc object for the window: 


CClientDC clientDC(this) ; 


The cClientDc constructor requires a pointer to the window for which the DC 
is being created. In this case, you just use the this pointer. Then, the program 
constructs a CBitmap object and uses it to create a bitmap that’s compatible 
with the window’s DC: 

m_pBitmap = new CBitmap; 

m_pBitmap ->CreateCompatibleBitmap(&clientDC, 640, 480); 
The CBitmap class’s member function, CreateCompatibleBitmap(), takes as 
arguments the address of the device context with which the bitmap must 
be compatible, and the width and height of the bitmap. The function 
CreateCompatibleBitmap() is an MFC version of a Windows API function 
of the same name. 


Now, because this bitmap must be associated with a DC before you can draw 
on it, the program creates a memory DC in which to hold the bitmap: 


CDC memDC; 
memDC.CreateCompatibleDC(&clientDC) ; 


The memory DC can be an object of the coc class. Calling the class’s 
CreateCompatibleDC() function (which is an MFC version of a Windows API 
function of the same name) ensures that the memory DC is compatible with 


the client window’s DC. The function’s single argument is the address of the 
DC with which the new DC should be compatible. 
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Phrases like “create a compatible DC” sound very technical and can be confusing, 
which is unfortunate because creating a compatible DC is really a simple process. As 
you know, a device context is simply a structure that describes the attributes for a 
device. These attributes include things such as a pen color, a drawing surface of a 
specific size, a default font, and so on. Creating a compatible DC mn means 
creating a DC that has the same attributes as another DC. 


Imagine that you're sitting at a table with a sheet of 8 1/2 x 11-inch typing paper, a 
red pencil, and a stencil for drawing Old English lettering. You can think of these 
drawing implements as a device context. Now, suppose a friend shows up who 
wants to help you with your project. So, you give her another set of supplies just like 
yours. Giving your friend a second set of identical drawing supplies is similar to what 
happens when you create a compatible DC. 


Next, because you want to draw on the bitmap you created, you must associ- 
ate the bitmap with the DC (called “selecting the bitmap into the DC”): 


memDC.SelectObject(m_pBitmap) ; 


The SelectObject() function, the cnc class’s version of a Windows API func- 
tion of the same name, takes care of this task. Its single argument is a pointer 
to the bitmap. 


After selecting the bitmap into the DC, the program has an in-memory sur- 
face on which it can draw the image that will be transferred to the window’s 
display. The first thing the program must do to prepare this surface is to paint 
it entirely white: 

CBrush* brush = new CBrush(RGB(255, 255,255) ); 


memDC.FillRect(CRect(®, ©, 639, 479), brush); 
delete brush; 


Here, the program creates a white brush and uses the brush in a call to the 
FillRect() function, after which the program deletes the brush. To construct 
a CBrush object, you need only supply the RGB values for the brush’s colors. 
These values are the intensity of the red, green, and blue color components, 
respectively, which can be any value from 0 to 255. The higher the color 
value, the brighter the color component. 


The FillRect() function, which is the coc class’s version of a Windows API 
function, takes two arguments: a CRect object containing the position and 
size of the rectangle to fill, and the brush with which to fill the rectangle. 
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At this point, the bitmap is a white rectangle. The next thing to do is to draw 
the lines that make up the dungeon grid. As you already know, this line- 
drawing is performed by the CDundesView class’s DrawGrid() function: 


DrawGrid(&memDC) ; 


Examining the OnDraw() Function 

All the bitmap finagling that you’ve done in OnCreate() only creates an image 
in memory. That image still doesn’t appear in Dungeon Designer’s window. 
As you know, in an AppWizard-generated application, it’s the OnDraw() func- 
tion that is charged with actually updating a window’s display. 


In the OnDraw() function, the program first creates a memory DC that’s com- 
patible with the DC passed to the function: 


CDC memDC; 
memDC.CreateCompatibleDC(pDC) ; 


The program then selects the bitmap (which contains the image to be drawn 
to the window) into the memory DC: 


memDC.SelectObject(m_pBitmap) ; 


Finally, a quick call to the window DC’s BitB1t() function transfers the 
bitmap’s image from the memory DC to the window’s client area: 


pDC->BitB1t(®, ©, 640, 480, &memDC, ©, ®, SRCCOPY) ; 


BitBlt(), which is the cpc class’s version of a Windows API function, takes 
eight arguments: the X,Y coordinates of the bitmap’s destination rectangle, 
the width and height of the destination rectangle, a pointer to the source DC 
(the one containing the bitmap), the X,Y coordinates of the rectangle in the 
bitmap to copy, and a flag indicating how the source rectangle should be 
combined with the destination rectangle. The flag srccoPY means that the 
bitmap will completely overwrite any other image in the window. 
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You’ve now got Dungeon Designer so that it can display the dungeon grid 
and repaint its display when necessary. However, you still can’t create a dun- 
geon layout, one reason being that the program doesn’t yet have a complete 
document class in which to store the data that makes up a dungeon. You'll 
take care of that problem now. 
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Although AppWizard-generated programs are usually more suited for business 
applications such as word processors and spreadsheets, there’s no reason 
(unless the extra overhead slows your program) that you can’t take advantage 
of the Document/View model in a computer game. After all, every game pro- 
gram has data that it must save and load. In addition, every game program 
must display that data in one way or another. 


In an AppWizard program, the document class handles the application’s 
loading and saving of data, and the view class displays and manipulates that 
data. In the steps that follow, you'll customize Dungeon Designer’s document 
class so that it can save, load, and store dungeon data. 


The complete source code and executable file for this step in the creation of the 
Dungeon Designer application can be found in the CHAPO6\DUNDES4 directory of 
this book’s CD-ROM. 


1. Load the DUNDEDOC.H file and add the following line to the At- 
tributes section of the class’s declaration, right after the first public 
keyword: 


cPtrArray m_Dungeon; 


This line declares m_Dungeon, a CPtrArray object, as a data member of the 
CDundesDoc Class. This array of pointers, which you’ll learn about later in 
this section, holds the data that defines a dungeon floor. 


2. Also in DUNDEDOC.H, add the following function declaration to the 
class, right after the first protected keyword in the Implementation 
section: 


BOOL InStartingWalls(int squareNum) ; 


This line declares InStartingWalls() as a member function of the 
CDundesDoc Class. 


3. Load DUNDEDOC.CPP and add the following to the OnNewDocument () 
function, right after the // (SDI documents will reuse this document) 
comment: 


// Iterate through each square in the dungeon. 
for (UINT i=@; i<DUNGEONSIZE; ++i) 
{ 
// Construct a new item for the current square. 
CItem* pItem = new CItem; 
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// If the square must contain a wall... 
if (InStartingWalls(i) ) 


{ 
pItem->iType = Wall; 
pItem->iNumber = 0; 
pItem->iValue = 0; 

} 


// If the square must contain the level's exit... 
else if (i == 61) 


{ 
pItem->iType = Door; 
pItem->iNumber = 5; 
pItem->iValue = 0; 

} 


// If the square must contain 
// the level's boss monster... 
else if ( i == 62) 


{ 
pItem->iType = Monster; 
pItem->iNumber = 2; 
pItem->iValue = 50; 

} 

// Otherwise, the square is empty... 

else 

{ 


pItem->iType = Empty; 
pItem->iNumber = 0; 
pItem->iValue = 0; 

} 


// Add the new item to the array. 
m_Dungeon.Add(pItem) ; 


The preceding lines initialize a default dungeon layout whenever the 
user starts a new document. You'll learn about the OnNewDocument ( ) 
function later in this chapter. 


4. Use ClassWizard to add the DeleteContents() function to the 
CDundesDoc class, as shown in figure 6.23. The DeleteContents() func- 
tion is called whenever a new document is created, to ensure that the 
contents of the old document have been deleted. 


5. Add the following code to DeleteContents(), right after the // TODO: 
Add your specialized code here and/or call the base class comment: 


// Get the size of the array. 
UINT size = m_Dungeon.GetSize() ; 
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// If the array contains pointers, delete the 
// pointers and empty the array. 
if (size > 0) 


{ 


} 


for (UINT i=@; i<DUNGEONSIZE; ++i) 
delete m_Dungeon.GetAt (i); 
m_Dungeon.RemoveA11() ; 


These lines remove all pointers (and the objects to which those pointers 
refer) from memory and the m_Dungeon array. You'll learn more about 
DeleteContents() later in this chapter. 


Fig. 6.23 

Adding the 
DeleteContents() 
function to 
Dungeon Designer. 


Fl 
ID_FILE_OPEN 


ID_FILE_PRINT 


6. Add the following function to the end of the DUNDEDOC.CP? file: 


BOOL CDundesDoc::InStartingWalls(int squareNum) 


{ 


// Determine whether the square is one of 
// the default wall squares. 
if ((squareNum > -1) && (squareNum < ROWSIZE) ) 
return TRUE; 
if ((squareNum > (COLSIZE-1)*ROWSIZE) && 
(squareNum < COLSIZE*ROWSIZE) ) 
return TRUE; 
if ((squareNum % ROWSIZE == @) |} 
(squareNum % ROWSIZE == ROWSIZE-1) ) 
return TRUE; 
if ((squareNum == 93) |; (squareNum == 94)) 
return TRUE; 
return FALSE; 
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The preceding function determines whether a square in the dungeon 
grid must contain one of the default walls. The default walls include the 
walls around the outside of the dungeon grid, as well as the walls that 
make up the entrance to the next dungeon floor, found in the dungeon 
grid’s top right corner. Default walls cannot be removed from the grid. 


7. Find the Serialize() function in the DUNDEDOC.CPP file and add 
the following code right after the // TODO: add storing code here 
comment: 

// Iterate through each dungeon square, sending 


// its contents to the output stream. 
for (UINT i=0; i<DUNGEONSIZE; ++i) 


{ 
CItem* pItem = (CItem*) m_Dungeon.GetAt (i); 
ar << pItem->iType; 
ar << pItem->iNumber; 
ar << pItem->iValue; 
} 


The preceding lines save the dungeon-grid data to disk. You'll learn 
more about the Serialize() function later in this chapter. 


8. In the same function, add the following code right after the // TODO: 
add loading code here comment: 
// Iterate through each dungeon square, 


// loading its contents from the input stream. 
for (UINT i=; i<DUNGEONSIZE; ++i) 


{ 
CItem* pItem = new CItem; 
ar >> pItem->iType; 
ar >> pItem->iNumber; 
ar >> pItem->iValue; 
m_Dungeon.Add(pItem) ; 

} 


// Tell the view to update its display. 
UpdateAllViews (NULL); 


The preceding lines load the dungeon-grid data from disk. 


9. Load DUNDES.H and add the following line to the constants you’ve 
already defined at the top of the file: 


const DUNGEONSIZE = 1024; 


The preceding line defines a constant that represents the total number 
of squares in the dungeon grid. 


10. Right after the constants in DUNDES.H, add the following structure 
declaration: 
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struct CItem 
{ 
WORD iType; 
WORD iNumber; 
WORD iValue; 
F3 
The preceding lines declare a structure for holding the values that repre- 
sent an item in the dungeon grid. Such items include doors, monsters, 
weapons, armor, and so on. Later in this chapter, you’ll see how this 


structure is used in the program. 


This completes version 4 of Dungeon Designer. To compile the program, 
select the Project menu’s Build command. Visual C++ then compiles and 
links the application. 


Running Dungeon Designer, Version 4 

When you run the new version of Dungeon Designer, you'll discover that the 
program looks no different than it did before. Nevertheless, Dungeon De- 
signer now has a complete document class that can load, save, and store data 
for a dungeon grid. 


At this point, if you were to save a file from Dungeon Designer, it would save 
only the default items that get initialized by the OnNewDocument() function. 
These items include the outside wall, the walls that make up the entrance to 
the next dungeon floor, the door to that entrance, and the monster that 
defends the door. 


After saving the file, you can use the File menu’s Open command to reload it. 
Unfortunately, because Dungeon Designer does not yet display items in the 
dungeon grid, loading a file doesn’t change the display. In later sections of 
this chapter, you’ll add the code needed to display, modify, and print the 
dungeon grid. But for now, take a look at how the document class works. 


Examining the Citem Structure 

As you know from using Dungeon Designer in the previous chapter, each 
square in the dungeon grid contains a single item. That item can be one of 
several types: Empty, Wall, Door, Monster, Treasure, Key, Sword, Armor, and 
Potion. These items are similar to one another in that they are defined by 
certain values. For example, a key and a door must have an item number that 
determines which key opens which door. Similarly, a potion has an item 
number and an item value. The item value determines how many hit points 
the potion can heal. 
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The easiest way to store the values that make up an item is to place them into 
a structure. In Dungeon Designer, that structure is CItem, as shown in the 
following: 


struct CItem 


WORD iType; 

WORD iNumber; 

WORD iValue; 

}; 

The CItem structure contains the three values that define an item. The iType 
member indicates whether the item is a potion, door, monster, and so on. 
The iNumber member determines which type of potion, door, monster, and so 
on that the structure defines. (For example, you may remember that you can 
have three types of monsters on a dungeon floor. So, for a monster, iNumber 
would be 0, 1, or 2.) The ivalue member holds the item value for the item, 
the meaning of which changes from item to item. (If you don’t remember 
this stuff, review the Dungeon Designer instructions in Chapter 5, “Playing 
Aztec Adventure.”) 


A dungeon floor’s data set consists of an array of pointers. Each pointer in the 
array points to a CItem structure that defines the item for the equivalent dun- 
geon square. Because the dungeon grid in Aztec Adventure is 32 x 32, it takes 
1,024 CItem structures to define a complete floor. The pointers to these 1,024 
structures are stored in the m_Dungeon array, which is a CPtrArray object. 


Examining the m_Dungeon Array 

Visual C++ includes an extensive library of classes that you can use in your 
own programs. This library includes a number of classes for handling various 
types of arrays. One such class is cPtrArray, which handles arrays of pointers. 
You need exactly this type of array to store the pointers to the 1,024 CItem 
structures that make up a dungeon floor’s data set. 


As you'll soon see, using one of Visual C++’s built-in classes such as cPtrArray 
lets you put together programs much faster, because the class already features 
the member functions you need to handle an object of that class. For ex- 
ample, you can add an item to a cPtrArray just by calling a single member 
function, Add(). Similarly, you can retrieve a value from a CPtrArray by call- 
ing the Getat() member function. You can even clear the entire array by 
calling the object’s RemoveAl11() member function. The best part is that you 
don’t have to worry about the size of the array because Visual C++ can auto- 
matically enlarge or shrink the array as necessary. 
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As you look over the functions that make up Dungeon Designer’s document 
class, you'll see in greater detail how the cPtrArray class, of which m_Dungeon 
is an object, works. 


Examining the DeleteContents() Function 

One of the advantages of using AppWizard’s Document/View model is that 
the document class handles a lot of the work involved in loading and saving 
the data that makes up a document. Dungeon Designer’s document class, 
called CDundesDoc, includes functions such as DeleteContents() and 
OnNewDocument() that handle the creation of a new dungeon-floor data set. 


When the user starts a new document—either by starting the program 
or by selecting the File menu’s New command—the member function 
DeleteContents() gets called, which ensures that any old data is properly 
deleted before the new data is initialized. 


The first thing Dungeon Designer’s version of DeleteContents() does is get 
the size of the m_Dungeon array: 


UINT size = m_Dungeon.GetSize(); 


The GetSize() function is a member of the cPtrArray class and returns the 
number of elements currently stored in the array. You already know that the 
array must have 1,024 elements to define a dungeon floor. So, shouldn’t 
GetSize() always return 1,024? 


Nope. Sometimes GetSize() will return 0, because DeleteContents() is always 
called before a new document is created—and that includes before the pro- 
gram has had a chance to add items to m_Dungeon. If you don’t check for valid 
data in DeleteContents(), your program will crash almost immediately. 


So, before trying to delete any items stored in m_Dungeon, the program checks 
size to make sure it’s greater than zero: 

if (size > 0) 
If size is equal to zero, the DeleteContents() function does nothing. Other- 


wise, it deletes each of the CItem objects pointed to by the pointers in the 
array: 


for (UINT i=@; i<DUNGEONSIZE; ++i) 
delete m_Dungeon.GetAt (i) ; 


Each iteration of this for loop calls the cPtrArray member function GetAt(), 
which returns the pointer stored in the array at index i. 
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After the for loop completes, the program has deleted all the CItem structures 
from memory. However, the m_Dungeon array still contains pointers to those 
deleted objects—a dangerous situation. A call to the cPtrArray RemoveA11() 
member function clears up this problem: 


m_Dungeon.RemoveA11(); 


The RemoveAll1() function simply clears all elements from the array. 


After DeleteContents() does its thing, the m_Dungeon array is guaranteed to be 
empty, ready to be filled with the default data set that defines a new dungeon 
floor. This new dungeon floor is defined in the OnNewDocument () function. 


Examining the OnNewDocument() Function 

When an application created by AppWizard begins, or when the user selects 
the File menu’s New command, the program calls the OnNewDocument() func- 
tion, which is responsible for initializing a new document. 


In Dungeon Designer, OnNewDocument ()’s task is to create a CItem structure for 
each item in the new dungeon-floor data set. It begins this task with a for 
loop that iterates through the squares in the grid: 


for (i=@; i<DUNGEONSIZE; ++i) 
Inside the loop, the program first creates a new CItem object: 
CItem* pItem = new CItem; 


It then calls InStartingWalls() to see whether the current square (represented 
by the loop index i) must contain a default wall: 


if (InStartingWalls(i)) 

If InStartingWalls() returns TRUE, the current square is made into a wall: 
pItem->iType = Wall; 
pItem->iNumber = 0; 


pItem->iValue = 0; 


If the current square is number 61, the square must contain the door to the 
next-floor entrance: 


else if (i == 61) 


{ 
pItem->iType = Door; 
pItem->iNumber = 5; 
pItem->iValue = 0; 

} 


If the square number is 62, the square must contain the monster that guards 
the entrance to the next floor: 
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else if ( i == 62) 


{ 
pItem->iType = Monster; 
pItem->iNumber = 2; 
pItem->iValue = 50; 

} 


Finally, if the square doesn’t need to be one of the default items, it’s made 
into an empty item: 


else 
{ 
pItem->iType = Empty; 
pItem->iNumber = 0; 
pItem->iValue = 0; 
} 
Once the program has defined the item for the square, it adds the item to the 


m_Dungeon array: 
m_Dungeon.Add(pItem) ; 


After the for loop runs its course, OnNewDocument() has fully defined the start- 
ing dungeon layout. 


The squares that make up a dungeon floor are numbered from 0 to 1,023, starting 
with 0 in the top left corner and moving horizontally through the rows until reaching 
the bottom right corner, which is square number 1,023. 


Examining the Serialize() Function 

In its document class, an AppWizard-generated program has a special func- 
tion that handles the loading and saving of data. This function is called 
Serialize(). 


Whenever the user chooses the File menu’s Load or Save commands (includ- 
ing Save As), the document class’s Serialize() function is called to do the 
actual loading and saving of the document’s data. By the time Serialize() 
gets called, the program has already (thanks to MFC) created a CArchive ob- 
ject to handle the data stream. 


CArchive is a Visual C++ class that represents an input/output stream associ- 
ated with a disk file. Like other Visual C++ classes (such as cPtrArray, with 
which you've already had some experience), CArchive provides many member 
functions that help you deal with input and output tasks. 


213 


214 


Chapter 6—Programming Dungeon Designer 


In the Serialize() function, the CArchive object ar is set up and ready to go. 
The function determines whether data needs to be saved or loaded by calling 
ar’s member function IsStoring(), which returns TRUE if data needs to be 
saved, and FALSE otherwise. 


If data needs to be saved, the program uses a for loop that iterates through 
each item in the m_Dungeon array: 


for (UINT i=0; i<DUNGEONSIZE; ++i) 


Within the loop, the program first gets a pointer to the CItem structure for the 
current item, which is represented by the loop variable i: 


CItem* pItem = (CItem*) m_Dungeon.GetAt(i); 


Each member of the structure is then saved to disk in much the same way 
you'd use any C++ stream: 

ar << pItem->iType; 

ar << pItem->iNumber; 

ar << pItem->iValue; 
As you can see from the preceding lines, the CArchive class (of which ar is an 
object) overloads the << operator so that the data item to the right of the 
operator gets sent to the output stream, which saves the item to the disk file 
associated with the ar object. (The user chooses the disk file using the usual 
Open and Save dialog boxes, both of which are handled completely by the 
program with no additional code from you.) 


If ar’s IsStoring() member function returns FALSE, the function must load 
data. Again, the loading takes place within a for loop that iterates through 
each item in the array. But, because the file is being loaded, the CItem struc- 
tures for each item have to be created: 


CItem* pItem = new CItem; 

Then the values for each member of the new CItem structure can be loaded: 
ar >> pItem->iType; 
ar >> pItem->iNumber; 


ar >> pItem->iValue; 


The overloaded >> operator in the CArchive class moves data from the disk file 
into the data item on the right. After loading the CItem structure with its 
values, the program adds the pItem pointer to the m_Dungeon array: 


m_Dungeon.Add(pItem) ; 


When the for loop completes, all 1,024 CItem structures will have been 
loaded from the archive object’s disk file. The last step is to call the document 
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class’s UpdateAllViews() function to notify the view class that it has new data 
to display: 


UpdateAllViews (NULL) ; 


You learned about the UpdateAllViews() function in Chapter 2, “Manipulat- 
ing Device-Independent Bitmaps.” 
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You now have a document class that can load, save, and store the data that 
represents a dungeon layout. Now, it’d be nice if you could see the data that 
the document class is storing, as well as modify that data in order to create 
any dungeon layout you want. In this next version of the Dungeon Designer 
application, you’ll add the code that’s needed to join the document and view 
classes and thus make Dungeon Designer functional. 


The complete source code and executable file for this step in the creation of the 
Dungeon Designer application can be found in the CHAPO6\DUNDESS directory of 
this book’s CD-ROM. 


1. Load the DUNDEVW.H file and add the following line to the 
CDundesView Class’s Attributes section, right after the m_pBitmap declara- 
tion you put there previously: 


COLORREF m_Colors[9]; 


This line declares m_Colors[], which is an array of COLORREF values, as a 
data member of the cDundesView class. This array will hold the color 
values for each of the items that must be displayed in the dungeon grid. 


2. Add the following lines to the view class’s Implementation section, 
right after the DrawGrid() function declaration you placed there 
previously: 


BOOL ClickInsideGrid(CPoint point) ; 

BOOL InStartingWalls(int squareNum) ; 

void HandleLeftClick(UINT squareNum, UINT col, UINT row); 
void PlaceWall(CItem* pItem, UINT x, UINT y); 

void PlaceItem(CItem* pItem, UINT x, UINT y, UINT mode) ; 
BOOL NotValidItem(CItem* pItem) ; 
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BOOL FindItem(WORD itemType, WORD itemNum, WORD& itemValue) ; 
void DrawSquare(UINT x, UINT y, CBrush* brush); 


These lines declare several protected member functions for the 
CDundesView class. l 


3. Load the DUNDEVW.CPP file and add the following code to the 
CDundesView constructor, after the single line you already put there: 


m_Colors[Empty] = RGB(255,255,255) ; 
m_Colors[Wall] RGB (128,128,128) ; 
m_Colors[Door] RGB(0,@,255) ; 
m_Colors[Key] = RGB(255,255,0); 
m_Colors[Monster] = RGB(255,0,Q); 
m_Colors[Treasure] = RGB(0,128,0); 
m_Colors[Sword] = RGB(255,0,255) ; 
m_Colors[Armor] = RGB(0,255,255) ; 
m_Colors[Potion] = RGB(0,255,Q) ; 


These lines initialize the m_Colors[] array to the color values needed to 
display the different types of objects in the dungeon grid. 


4. Use ClassWizard to add the OnUpdate() function to the CDundesView 
class, as shown in figure 6.24. 


Fig. 6.24 

Adding 

OnUpdate() to 

P 0 P CDundesView | 
the CDundes View sincere ee 
class. 
OnPrint 

ID_APP_ABOUT OnScroll 
ID_APP_EXIT OnScrollB 
ID_FILE_MRU_FILE1 
ID_FILE_NEW PostNcDestroy 
ID_FILE_OPEN PreCreateWindow 
ID_FILE PRINT |. PreTranslateMessage 
W OnltemsTreasure ON_ID_ITEMS_TREAS 
W OnitemsWall ON_ID_ITEMS_WALL: 


WW OnPreparePrinting 


OnUpdateltemsArmor __ON_ID_ITEMS_ARMOF, 


5. Add the following code to the OnUpdate() function, right after the 
// TODO: Add your specialized code here and/or call the base class 
comment: 


// Get a pointer to the document object. 
CDundesDoc* pDoc = (CDundesDoc*) GetDocument() ; 


Creating Dungeon Designer, Version 5 


// Create a DC for the window. 
CClientDC clientDC(this) ; 


// Create a memory DC that's 

// compatible with the window DC. 
CDC memDC; 
memDC.CreateCompatibleDC(&clientDC) ; 


// Select the dungeon-grid bitmap into the memory DC. 
memDC.SelectObject (m_pBitmap) ; 


// Iterate through each square in the dungeon grid. 
for (int i=@; i<DUNGEONSIZE; ++i) 


{ 


} 


// Get the currently indexed item. 
CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt (i) ; 


// Create and select a brush for the item. 
CBrush* brush = new CBrush(m_Colors[pItem->iType] ) ; 
CBrush* oldBrush = memDC.SelectObject(brush) ; 


// Calculate the pixel position to draw the square. 
UINT row = i / ROWSIZE; 

UINT col = i (row * ROWSIZE) ; 

UINT x = col * SQUARESIZE + OFFSET; 

UINT y row * SQUARESIZE + OFFSET; 


* oF 


// Draw the square on the bitmap. 
memDC.Rectangle(x, Y, 
X+SQUARESIZE+1, y+SQUARESIZE+1) ; 


// Restore the DC and delete the brush. 
memDC.SelectObject(oldBrush) ; 
delete brush; 


// Force the window to redraw. 
Invalidate(); 


These lines update the bitmap in memory that represents the image to 
be displayed in the program’s main window. You'll learn more about 
the OnUpdate() function later in this chapter. 


Use ClassWizard to create an OnLButtonDown() function in the 
CDundesView Class, as shown in figure 6.25. 


Add the following code to the OnLButtonDown() function, right after the 
// TODO: Add your message handler code here and/or call default 


comment: 


// If the user clicked in the dungeon grid... 
if (ClickInsideGrid(point) ) 
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Fig. 6.25 

Adding 
OnLButtonDown() 
to the 

CDundes View class. 


} 


// Calculate the square's column and row. 

UINT col = ((point.x - OFFSET) / SQUARESIZE) * 
SQUARESIZE + OFFSET; 

UINT row = ((point.y - OFFSET) / SQUARESIZE) * 
SQUARESIZE + OFFSET; 


// Calculate the square's number. 
UINT squareNum = (col / SQUARESIZE) + 
(row / SQUARESIZE) * ROWSIZE; 


// If the square is not unchangeable... 
if (!InStartingWalls(squareNum) ) 
HandleLeftClick(squareNum, col, row); 


The OnLButtonDown() function gets called whenever the user presses the 
left mouse button when the mouse pointer is over the application’s 
window. You’ll learn more about this function later in the chapter. 


| CDundesView 
| . 
| WM_KEYDOWN 
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PONID FILE MAU FILE] = | | WM _LBUTTONDBLC 
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[ lio-FiLe-Pamt l | | wM_MoUSEMOVE 
| 
CE] OnltemsSword ON_ID_ITEMS_SWORI. 
JES OnitemsTreasure ON_ID_ITEMS_TREAS | 
E Onitemswall ON_|D_ITEMS_WALL:(asd 
'| 
OnPreparePiinting o l 


8. Add the following functions to the end of DUNDEVW.CPP: 


BOOL CDundesView::ClickInsideGrid(CPoint point) 


{ 


// Calculate width and height of grid in pixels. 
int gridSize = SQUARESIZE * ROWSIZE; 


// If the user clicked within the grid, return TRUE. 

if ((point.x < gridSize + OFFSET) && (point.x > OFFSET) && 
(point.y < gridSize + OFFSET) && (point.y > OFFSET) ) 
return TRUE; 
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// Otherwise, return FALSE. 
return FALSE; 
} 


BOOL CDundesView: : InStartingWalls(int squareNum) 
{ 
// Determine whether the square is one of 
// the default wall squares. 
if ((squareNum > -1) && (squareNum < ROWSIZE) ) 
return TRUE; 
if ((squareNum > (COLSIZE-1)*ROWSIZE) && 
(squareNum < COLSIZE*ROWSIZE) ) 
return TRUE; 
if ((squareNum % ROWSIZE == @) |; 
(squareNum % ROWSIZE == ROWSIZE-1) ) 
return TRUE; 
if ((squareNum == 93) į; (SquareNum == 94)) 
return TRUE; 
return FALSE; 


} 


void CDundesView: :HandleLeftClick(UINT squareNum, 
UINT col, UINT row) 


{ 
// Get a pointer to the document object. 


CDundesDoc* pDoc = GetDocument() ; 


// Get the item at the selected square. 
CItem* pItem = 
(CItem*) pDoc->m_Dungeon.GetAt (squareNum) ; 


// If the square already holds something... 
if (pItem->iType != Empty) 
{ 
// ...empty the square in memory... 
pItem->iType = Empty; 


//_...and redraw the square. 
CBrush* brush = new CBrush(RGB(255, 255,255) ) ; 
DrawSquare(col, row, brush); 


} 


// Otherwise, place the appropriate 

// type of item in the square. 

else if (m_mode == Wall) 
PlaceWall(pItem, col, row); 

else 
PlaceItem(pItem, col, row, m_mode) ; 


// Tell the document object 
// that it's been modified. 
pDoc ->SetModifiedFlag() ; 


} 
void CDundesView: :PlaceWall(CItem* pItem, UINT x, UINT y) 


219 


220 Chapter 6—Programming Dungeon Designer 


// Initialize the new wall item. 
pItem->iType = Wall; 
pItem->iNumber = 0; 
pItem->iValue = Q; 


// Create a brush for the wall from the color array. 
CBrush* brush = new CBrush(m_Colors[Wal1]); 


// Draw the new wall square on the screen. 
DrawSquare(x, y, brush); 


} 


void CDundesView: :PlaceItem(CItem* pItem, 
UINT x, UINT y, UINT itemType) 

{ 
// Display the Item dialog box. 
CItemDlg dlg; 
dig.m_number = Q; 
dig.m_value = Q; 
UINT result = dlg.DoModal(); 


// If the user exits the dialog box with the OK 


// button... 
if (result == IDOK) 
{ 


// Get the requested item number. 
UINT itemNumber = dlg.m_number; 


// See whether the item already exists. 
WORD itemValue; 
BOOL found = 
FindItem(itemType, itemNumber, itemValue) ; 
result = IDNO; 


// No such item yet, so ask if user wants 
// to create a new item of the requested type. 
if (!found) 
result = MessageBox("Create new item?", 
"Item", MB_ICONQUESTION {| MB_YESNO); 


// If it's okay to create the item... 
if ((result == IDYES) |; (found) ) 
{ 
// Change the item object from empty 
// to the new item. 
pItem->iType = itemType; 
pItem->iNumber = itemNumber; 
if (found) 
pItem->iValue = itemValue; 
else 
pItem->iValue 


dig.m_value; 


// Make sure the item number is within 
// proper bounds for the item type. 

if (NotValidItem(pItem) ) 

{ 


} 


} 
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MessageBox("Item Number Not Valid", 
“Invalid Item", 
MB_ICONEXCLAMATION | MB_OK); 

pItem->iType = Empty; 

itemType = Empty; 

pItem->iNumber = Q; 

pItem->iValue = Q; 


// Draw the new item on the screen. 
CBrush* brush = new CBrush(m_Colors[itemType] ) ; 
DrawSquare(x, y, brush); 


BOOL CDundesView: :NotValidItem(CItem* pItem) 


} 


BOOL notValid = FALSE; 


// Check each item type for valid item numbers. 
switch(pItem->iType) 


case Door: 
case Key: 
if (pItem->iNumber > 5) 
notValid = TRUE; 
break; 
case Monster: 
if (pItem->iNumber > 2) 
notValid = TRUE; 
break; 
case Sword: 
case Armor: 
if (pItem->iNumber > Q) 
notValid = TRUE; 


return notValid; 


BOOL CDundesView: :FindItem(WORD itemType, 


{ 


WORD itemNum, WORD& itemValue) 


// Get a pointer to the document object. 
CDundesDoc* pDoc = GetDocument() ; 


BOOL found = FALSE; 
Q; 


// Search through the item array until the item 
// is found or until the loop reaches the end 
// of the array. 

while ((!found) && (i<DUNGEONSIZE) ) 


// Get the currently indexed item. 
CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt (i); 
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10. 


11. 


// Check whether the items match. 
if ((pItem->iType == itemType) && 
(pItem->iNumber == itemNum) ) 
{ 
itemValue = pItem->iValue; 
found = TRUE; 


} 


// Increment index variable. 
++i; 


} 


return found; 


} 


void CDundesView::DrawSquare(UINT x, UINT y, CBrush* brush) 
{ 

// Create a DC for the window and a memory 

// DC compatible with the window DC. 

CClientDC clientDC(this) ; 

CDC memDC; 

memDC.CreateCompatibleDC(&clientDC) ; 


// Select the dungeon-grid bitmap into the memory DC. 
memDC.SelectObject(m_pBitmap) ; 


// Select the brush into both DCs. 
CBrush* oldBrush1 memDC.SelectObject (brush); 
CBrush* oldBrush2 clientDC.SelectObject (brush) ; 


"oul 


// Draw the square into both DCs. 
memDC.Rectangle(x, y, 

x + SQUARESIZE + 1, y + SQUARESIZE + 1); 
clientDC.Rectangle(x, y, 

x + SQUARESIZE + 1, y + SQUARESIZE + 1); 


// Restore DCs and delete the brush. 
memDC.SelectObject(oldBrush1 ) ; 
clientDC.SelectObject(oldBrush2) ; 
delete brush; 


} 


You'll learn about these functions later in the chapter. 


Start Visual C++’s dialog editor and create the dialog box shown in 
figure 6.26. 


Double-click the upper edit control and give it the IDC_NUMBER ID, as 
shown in figure 6.27. Give the lower edit control the ID IDC_VALUE. 


Start ClassWizard. The Add Class dialog box appears. In the Class Name 
edit control, type CItemD1g, as shown in figure 6.28. Click the Create 
Class button to associate the CItemD1g class with the dialog box. 
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| 1c -IDD_ DIALOG! (Dialog) Fig. 6.26 
‘aera T | Creating the Item 
3 j dialog box. 
l 
Fig. 6.27 
Giving the edit 


controls their IDs. 


Fig. 6.28 
Associating the 
dialog box with 
the new CltemDlg 
class. 


12. In the MFC ClassWizard dialog box, click on the Member Variables tab. 
The Member Variables options page appears, as shown in figure 6.29. 


13. Click on IDC_NUMBER in the Control IDs list box, and then click the Add 
Variable button. The Add Member Variable dialog box appears. In the 
Member Variable Name edit control, type m_number. In the Variable 
Type box, select UINT (see fig. 6.30). 
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Fig. 6.29 | -MFC ClassWizard 
The Member o aatiaeabanetes 
Variables options 


page. 


Fig. 6.30 |Add Member Variable 
The Add Member 
Variable dialog 
box. 


14. Using the technique in step 13, create a UINT member variable named 
m_value for the edit control with the IDC_VALUE ID. (When you’re 
through, the MFC ClassWizard dialog box should look like figure 6.31.) 
Close the dialog box (by selecting the OK button), dialog editor, and 
the resource window. 


15. Add the following line to the top of the DUNDEVW.CPP file, right after 
the #endif: 


#include "itemdlg.h" 
This line gives the CDundesView class access to the CItemD1g class. 
This completes version 5 of Dungeon Designer. To compile the program, 


select the Project menu’s Build command. Visual C++ then compiles and 
links the application. 
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Fig. 6.31 

The MFC 
ClassWizard dialog 
box after creating 
member variables 
for the dialog box. 


` MFC ClassWizard 


Running Dungeon Designer, Version 5 

When you run the new version of Dungeon Designer, you see the window 
shown in figure 6.32. Now, the window’s dungeon grid shows the items that 
make up the dungeon. You can also now add items to the dungeon by select- 
ing an item from the Items menu and clicking on a square in the dungeon 
grid. When you do, the Item dialog box appears, asking for the item’s num- 
ber and value. Click the dialog box’s OK button, and the item appears on the 
screen as a colored square. 


Untitled - punjena {Ee 3 : f= Fig. 6.32 
Dungeon Designer, 


Pei lel lol 2] | Version 5. 
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Examining the OnUpdate() Function 

In an AppWizard-generated program, the view class’s OnDraw() function usu- 
ally takes care of redrawing the window whenever it needs it. However, in 
order to have fast window redraws, Dungeon Designer uses a kind of layered 
approach to screen drawing. Dungeon Designer’s view class (CDundesView) 
uses its OnDraw() function to transfer a bitmap from memory to the screen. 
Other than that bitmap transfer, OnDraw() does no other window painting. 


Obviously, the bitmap that OnDraw() displays must be modified somewhere in 
the program. These modifications occur whenever the user places a new ob- 
ject on the grid or when a new dungeon is created or loaded from disk. Later 
in this chapter, you’ll see what happens in the program when the user adds 
an item to the dungeon grid. For now, this discussion will concentrate on the 
OnUpdate() function, which is called whenever the user starts a new dungeon 
layout or loads one from disk. 


As I said previously, the view class’s OnDraw() function ordinarily takes care of 
every case of window repainting, even when the user loads new data from 
disk. In Dungeon Designer, however, trying to update the screen in OnDraw() 
using the raw data stored in m_Dungeon makes the program look clunky. This 
is because it takes a couple of seconds to read through the m_Dungeon array 
and paint each item found there onto the on-screen grid. The program would 
look a lot more sophisticated if this drawing were accomplished “behind the 
user’s back.” 


The solution is to draw the new screen image on a bitmap in memory and 
then transfer that bitmap all at once to the screen display. But where can you 
intercept the window-drawing process so that you can draw the bitmap be- 
fore OnDraw() transfers it to the screen? As you’ve probably guessed from this 
section’s heading, the answer is the OnUpdate() function. 


In an AppWizard-generated program, calling the document class’s 
UpdateAllViews() function causes each view class’s OnUpdate() function to be 
called. OnUpdate(), which is implemented in the CView base class, ordinarily 
invalidates the view window’s entire client area, which results in a call to 
OnDraw(), where the screen updating is actually done. However, you can over- 
ride OnUpdate() in order to change the way your application repaints its win- 
dow when the document changes. That’s what Dungeon Designer does. 


Because the data that the view must display is stored in the document class, 
Dungeon Designer’s OnUpdate() function first gets a pointer to the document: 
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CDundesDoc* pDoc = (CDundesDoc*) GetDocument() ; 


Now, in order to draw on the bitmap in memory, the program must create a 
memory DC that’s compatible with the screen DC: 

CClientDC clientDC(this) ; 

CDC memDC; 

memDC.CreateCompatibleDC(&clientDC) ; 
With the compatible DC created, OnUpdate() can now select the bitmap into 
the memory DC: 


memDC.SelectObject(m_pBitmap) ; 


In order to draw the appropriate item in each square of the dungeon grid, the 
program must read through the document’s m_Dungeon array. A for loop pro- 
vides the perfect mechanism for this task: 


for (int i=0; i<DUNGEONSIZE; ++i) 
Inside the for loop, the program first gets a pointer to the next item in the 
m_Dungeon array: 


CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt (i); 


Then, the item type is used as an index into the m_Colors[] array, in order to 
create a brush of the appropriate color for the item: 

CBrush* brush = new CBrush(m_Colors[item]) ; 

CBrush* oldBrush = memDC.SelectObject (brush); 
Once the program has a brush for the object, it needs to calculate where on 
the screen the item must be drawn: 

UINT row = i / ROWSIZE; 

UINT col = i - (row * ROWSIZE) ; 

UINT x = col * SQUARESIZE + OFFSET; 

UINT y = row * SQUARESIZE + OFFSET; 
With a brush created and the square’s location in the grid calculated, 
OnUpdate() can draw the item by calling the DC class’s Rectangle() function: 

memDC.Rectangle(x, Y, 

X+SQUARESIZE+1, y+SQUARESIZE+1); 

Finally, in preparation for the next iteration through the loop, the function 
selects the old brush into the memory DC and deletes the new brush: 


memDC.SelectObject(oldBrush) ; 
delete brush; 


When the loop finishes, the bitmap’s dungeon grid is completely updated 
and ready to transfer to the screen. Calling the view class’s Invalidate() 
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function forces a call to OnDraw(), where the bitmap is transferred to the 
window’s client area: 


Invalidate(); 


Examining the OnLButtonDown() Function 

If it were just a matter of waiting a second or two for the screen to redraw 
when starting a new dungeon or activating the window, the slow update 
wouldn’t be much of a problem. However, the slow screen updates would 
also cause a noticeable lag between a mouse click on a grid square and the 
appearance of the item, especially on items toward the bottom of the grid, 
since it takes longer to get to those items as the program reads through the 
m_Dungeon array. 


In order to avoid these slow screen updates when only a single square needs 
to be updated, Dungeon Designer draws the square directly on the screen, 
without bothering with OnUpdate() or OnDraw(), and also updates the bitmap 
in memory. In fact, every time you place an item on the dungeon grid, that 
item gets drawn twice, once directly on the screen and once on the bitmap in 
memoty. 


Whenever the user wants to place a new item in the dungeon grid, she left- 
clicks the square that will hold the new item. This causes the program’s 
OnLButtonDown() function to be called. 


OnLButtonDown() first checks whether the user’s mouse click was inside the 
grid area: 


if (ClickInsideGrid(point) ) 


The ClickInsideGrid() function returns TRUE if the mouse pointer was over 
the dungeon grid and returns FALSE if the mouse pointer was over some other 
part of the window. If the user’s mouse click wasn’t over the grid, there’s 
nothing to do, because the user is not allowed to place an item anywhere 
except within the boundaries of the grid. 


If the mouse click is inside the grid, OnLButtonDown() calculates the number of 
the square on which the user clicked: 


UINT col = ((point.x - OFFSET) / SQUARESIZE) * 
SQUARESIZE + OFFSET; 

UINT row = ((point.y - OFFSET) / SQUARESIZE) * 
SQUARESIZE + OFFSET; 

UINT squareNum = (col / SQUARESIZE) + 
(row / SQUARESIZE) * ROWSIZE; 
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The point data object (an instance of the CPoint class) is passed as a param- 
eter to OnLButtonDown(). It holds the coordinates of the user’s mouse click. 


Once the function has the square number, it can check whether the square is 
one of the default walls that cannot be modified: 


if (!InStartingWalls(squareNum) ) 


Finally, if the square is one that the user can edit, the function calls 
HandleLeftClick(), which is the function that determines what to do with 
the square: 


HandleLeftClick(squareNum, col, row); 


Examining the HandleLeftClick() Function 

When the user clicks on the dungeon grid, she wants to do one of two things: 
place a new item in the grid or delete an existing item. The HandleLeftClick() 
function determines what the user wants to do. 


So that it can access the m_Dungeon array, this function first gets a pointer to 
the document class: 


CDundesDoc* pDoc = GetDocument() ; 


It then calls the m_Dungeon array class’s GetAt() function to get the item stored 
in the square that the user selected: 


CItem* pItem = 
(CItem*) pDoc->m_Dungeon.GetAt(squareNum) ; 


The item’s type determines whether the square already holds an item: 
if (pItem->iType != Empty) 


If the square is not empty, the user must want to delete the item currently in 
the square. To do this, HandleLeftClick() sets the item type to Empty: 


pItem->iType = Empty; 
It then redraws the square in white, leaving it cleared: 


CBrush* brush = new CBrush(RGB(255, 255, 255) ) ; 
DrawSquare(col, row, brush); 


The DrawSquare() function draws a rectangle in the grid square located at col, 
row, using the brush given as its third argument. 


If the selected square is empty, the user obviously wants to place an item 
there. This item could be a wall or some other item, such as a door, treasure, 
or key. Because the program handles walls differently from other items, a 
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special function, PlaceWa1l1(), is called if the current mode is set to Wall. Oth- 
erwise, the function calls PlaceItem(): 
else if (m_mode == Wall) 
PlaceWall(pItem, col, row); 


else 
PlaceItem(pItem, col, row, m_mode) ; 


You'll look at the DrawSquare(), PlaceWall(), and PlaceItem() functions in 
the sections that follow. The HandleLeftClick() function, however, ends by 
calling the document class’s SetModifiedFlag() function: 


pDoc ->SetModifiedFlag() ; 


Whenever the document in an AppWizard-generated program is modified, 
you should call SetModifiedFlag(), which tells the document object that 
the file needs to be saved before the program ends. If you don’t call 
SetModifiedFlag(), when the user tries to exit the program, she won’t be 
warned that the current document needs to be saved, and she will lose her 
work. 


Examining the DrawSquare() Function 

In Dungeon Designer, it’s the DrawSquare() function that actually places 
an item on the dungeon grid. To avoid a sloppy screen update, however, 
DrawSquare() draws the square directly on the screen, as well as on the in- 
memory bitmap, giving the user an instant response to her mouse click. 


First, DrawSquare() gets a device context for the view window, and then it 
creates a memory DC that’s compatible with the window’s DC: 
CClientDC clientDC(this) ; 
CDC memDC; 
memDC.CreateCompatibleDC(&clientDC) ; 


DrawSquare() then selects the bitmap holding the screen’s image into the 
memory DC, where the program can draw on it: 


memDC.SelectObject(m_pBitmap) ; 


A call to both of the DC’s SelectObject() member functions associates the 
brush that was passed into the function with both DCs: 


CBrush* oldBrush1 
CBrush* oldBrush2 


memDC.SelectObject (brush); 
clientDC.SelectObject(brush) ; 


DrawSquare() can then call both DC objects’ Rectangle() member functions 


to draw the rectangle on both the screen and on the in-memory bitmap: 


memDC.Rectangle(x, y, 
x + SQUARESIZE + 1, y + SQUARESIZE + 1); 
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clientDC.Rectangle(x, y, 
x + SQUARESIZE + 1, y + SQUARESIZE + 1); 
Keeping the bitmap updated this way ensures that when OnDraw() needs to 
repaint the window’s client area, the bitmap image will contain the right 
image. 


Finally, the function selects the old brushes back into the window and 
memory DCs, freeing the brush used to draw on the bitmap. This brush is 
then deleted: 

memDC.SelectObject(oldBrush1) ; 


clientDC.SelectObject(oldBrush2) ; 
delete brush; 


Examining the PlaceWall() Function 

Of the many items the user may want to place into a dungeon layout, the 
wall is the easiest to handle. This is because a wall has no meaningful item 
number or item value. Therefore, no values need to be requested from the 
user. The program can just plop the wall down, as is done by the PlaceWal1() 
function. 


A pointer to a CItem object and the X,Y coordinates of the item are passed 
into the function. PlaceWall() first initializes this CItem object to a wall: 
pItem->iType = Wall; 
pItem->iNumber = 0; 
pItem->iValue = Q; 
The function then creates the brush needed to draw the wall item and passes 
the brush along with the object’s X,Y coordinate to DrawSquare(): 
CBrush* brush = new CBrush(m_Colors[Wall1]) ; 
DrawSquare(x, y, brush); 
As you already know, DrawSquare() draws the item on both the screen and 
the in-memory bitmap, and then deletes the brush. 


Examining the Placeltem() Function 

Placing walls in the dungeon is much easier than placing other types of 
items. That’s because items like swords and armor have values that must be 
retrieved from the user. Moreover, these values must be checked to ensure 
that they fall within the right range of values for the specific object. All this 
extra nastiness is taken care of by the PlaceItem() function. 


PlaceItem()’s four parameters are a pointer to a CItem object, the X,Y coordi- 
nates of the object on the grid, and the type of item (Door, Monster, Key, and 
so on) that the user wants to create. 
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Before PlaceItem() can put an item in the dungeon grid, it must know the 
values that will be associated with the item. This means querying the user 
with a dialog box. After the user types the required values into the dialog 
box’s edit controls, the program can extract the values from the dialog-box 
class’s data members. 


The first step is to create a dialog-box object: 
CItemDlg dlg; 


You may remember that, when you created this version of Dungeon De- 
signer, you used the dialog-box editor to create the Item dialog box. You then 
associated that dialog box with the CItemD1g class. So, constructing a dialog- 
box object for the Item dialog box is just a matter of constructing a CItemD1g 
object. 


You may also remember that you associated data members with the dialog 
box’s two edit fields. Those data members, called m_number and m_value, 
should be set to O before the dialog box appears on the screen, because the 
values they contain will appear in the dialog box: 

dlg.m_number = ð; 

dlg.m_value = 0; 
Once the dialog-box object is ready to go, a quick call to the object’s 
DoModal() function displays the dialog box on the screen and enables the user 
to interact with it: 


UINT result = dlg.DoModal() ; 


The value returned from DoModal() is the ID of the button the user selected to 
exit the dialog box. In the case of a CItemD1g object, that ID will be IDOK or 
IDCANCEL. (Bet you can’t guess which ID goes with which button!) If the user 
exits with IDOK, she wants to place the item in the dungeon grid. In this case, 
the program starts by retrieving the item’s number: 


UINT itemNumber = dlg.m_number; 


The program then calls the FindItem() function to determine whether the 
user has previously created an object of the specified type and number: 
WORD itemValue; 


BOOL found = 
FindItem(itemType, itemNumber, itemValue) ; 


FindItem()’s three arguments are the type of item the user wants to create, 
the item number she gave the item, and a reference to a WORD value in which 
the function will return the item’s item value if the item already exists. After 
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calling FindItem(), the Boolean value found will be TRUE if the item already 
exists and FALSE if this is a new item. For example, if the user is trying to 
place a monster number 0, and that monster already was placed previously 
on the grid, FindItem() returns TRUE, with the monster’s value stored in 
itemValue. Otherwise, FindItem() returns FALSE and itemValue contains no 
valid value. 


If FindItem() can’t find an instance of the chosen item, the program asks the 
user whether she wants to create a new item: 
if (!found) 


result = MessageBox("Create new item?", 
"Item", MB _ICONQUESTION {| MB_YESNO) ; 


The MessageBox() function displays a message box on the screen containing 

a line of text and one or more buttons that the user can click to answer the 
query. The function’s arguments are the line of text to display, the dialog-box 
name that will appear in the title bar, and a series of flags that indicate which 
buttons and icons will appear in the message box. In this case, the message 
box shown in figure 6.33 appears, which contains a question-mark icon, a Yes 
button, and a No button. (Please refer to your Visual C++ manuals for more 
information on the MessageBox() function and its flags.) 


After the user exits the message box, result contains the ID of the button she 
clicked. If the user clicked the IDYES button, or FindItem() found that the 
item already existed, PlaceItem() sets the new CItem object to its appropriate 
values: 


pItem->iType = itemType; 
pItem->iNumber = itemNumber; 
if (found) 
pItem->iValue 
else 
pItem->iValue = dlg.m_value; 


itemValue; 


Notice that, if the item already existed, the new CItem object gets its ivalue 
from itemValue, which is the item value returned by FindItem(). Otherwise, 
the new CItem object gets its ivalue from the value the user typed into the 
dialog box’s IDC_VALUE edit box, the value for which is stored in the CItemD1lg 
class’s m_value data member. 
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Fig. 6.33 
A typical message 
box. 


Tip 

A message box is a 
handy way to get 
information from 
the user without 
having to create a 
full-fledged dialog 
box. 
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Before adding the new CiItem object to the dungeon grid, however, the pro- 
gram must be sure that the item’s iNumber is within the proper bounds for the 
item type. A call to the Boolean function NotValidItem() inside an if state- 
ment handles this task: 


if (NotValidItem(pItem) ) 


NotValidItem() simply checks the item’s iNumber member and returns FALSE if 
that value is acceptable or TRUE if it isn’t. For example, you can have only six 
different key and door types, numbered 0 through 5, in a dungeon. If you 
tried to create a key with an iNumber of 6, NotValidItem() would return TRUE, 
indicating that the item is not valid. 


If the item is invalid, the program tells the user of her mistake and returns 
the item to its original Empty type: 
MessageBox("Item Number Not Valid", 
"Invalid Item", 
MB_ICONEXCLAMATION {| MB_OK) ; 
pItem->iType = Empty; 
itemType = Empty; 
pItem->iNumber = 0; 
pItem->iValue = 0; 
However the new item ends up—even empty—PlaceItem() must finally draw 
the item on the dungeon grid: 


CBrush* brush = new CBrush(m_Colors[itemType]) ; 
DrawSquare(x, y, brush); 


Examining the FindItem() Function 

If the user has previously placed a certain item type in the dungeon grid, 
there’s no need to request information about that item the next time she 
wants to place it in the grid. Because all the items in the grid are located in 
the document class’s m_Dungeon array, discovering whether a certain object 
already exists is just a matter of scanning the m_Dungeon array. This is done in 
the FindItem() function. 


So that the function can access the m_Dungeon array, FindItem() first gets a 
pointer to the CDundesDoc class: 


CDundesDoc* pDoc = GetDocument() ; 


The program then initializes a couple of variables that will be used as control 
variables in a while loop: 
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BOOL found = FALSE; 

int i = 90; 
The while loop executes until found becomes TRUE or i is equal to DUNGEONSIZE 
(defined as 1024): 


while ((!found) && (i<DUNGEONSIZE) ) 


Inside the loop, the program retrieves a pointer to the CItem object indexed 
by the current value of the loop variable i: 


CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt(i); 


The program then checks whether the item’s type and number match the 
item type and number of the item for which the function is searching: 

if ((pItem->iType == itemType) && 

(pItem->iNumber == itemNum) ) 

If there’s a match, the user has previously placed an object like this on the 
grid. In this case, FindItem() sets itemValue to the item’s iValue member so 
that the calling function can retrieve it and changes the Boolean loop vari- 
able found to TRUE, ending the while loop. 


If there is no match with the current item in the m_Dungeon array, the prog- 
ram increments the loop variable i and examines the next element of the 
m_Dungeon array. This continues until i becomes equal to 1024 or until the 
program finds a match. The value of found is then returned from the 
function: 


return found; 
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At this point, you can use Dungeon Designer to create dungeon floors for 
Aztec Adventure. The floors you create can be saved to disk and later loaded if 
you want to do more work on them. Dungeon Designer is lacking only two 
things: the ability to display item values for a particular grid square and the 
ability to print dungeon layouts. In this section, you’ll add these two impor- 
tant abilities. After you finish this section, Dungeon Designer will be 
complete. 


235 


236 Chapter 6—Programming Dungeon Designer 


al step in the creation of the 
xe CHAPO6\DUNDES directory of 


1. Use ClassWizard to add the onRButtonDown() function to the 
CDundesView Class, as shown in figure 6.34. 


Fig. 6.34 MFC Classwizard Ea 
Adding | (Matsage Maps | Member Variables |! OLE Automation | OLE Events} [a] >] 
OnRButtonDown() - 

to the 


CDundes View class. 


'WM_ABUTTONDBL( 
WM_RBUTTONUP | 
WM_SETCURSO 


WM_SETFOCUS 
WM_SHOWWIND 


2. Click the Edit Code button and then add the following lines to the 
OnRButtonDown() function, right after the // TODO: Add your message 
handler code here and/or call default comment: 


// If the user has clicked in the dungeon grid... 
if (ClickInsideGrid (point) ) 
{ 
// Get a pointer to the document. 
CDundesDoc* pDoc = GetDocument() ; 


// Calculate the clicked square's column, 
// row, and number. 

UINT col = (point.x - OFFSET) / SQUARESIZE; 
UINT row = (point.y - OFFSET) / SQUARESIZE; 
UINT itemNum = row * ROWSIZE + col; 


// Create a string object for displaying 
// the item's values. 
CString s("Type:\t"); 
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// Get the selected item. 
CItem* pItem = 
(CItem*) pDoc->m_Dungeon.GetAt(itemNum) ; 


// Add the item type to the string. 
switch (pItem->iType) 


{ 
case Empty: s += "Empty"; break; 
case Wall: s += "Wall"; break; 
case Door: s += "Door"; break; 
case Treasure: s += "Treasure"; break; 
case Monster: s += "Monster"; break; 
case Key: s += "Key"; break; 
case Sword: s += "Sword"; break; 
case Armor: s += "Armor"; break; 
case Potion: s += "Potion"; break; 

} 


// Add the item number to the string. 
s += "\nNumber:\t"; 

char num[10]; 

itoa(pItem->iNumber, num, 10); 

s += nun; 


// Add the item value to the string. 
s += "\nValue:\t"; 
itoa(pItem->iValue, num, 10); 

s += num; 


// Display the string containing 

// the item description. 

MessageBox(s, "Item", MB_OK); 

} 

The OnRButtonDown() function responds when the user right-clicks in- 
side the program’s window. In Dungeon Designer, OnRButtonDown( ) 
displays the attributes for the item in the grid square on which the 
user clicked. You’ll look at this function in greater detail later in this 
chapter. 


In the DUNDEVW.CPP file, find the OnPreparePrinting() function and 
add the following lines right after the function’s opening brace: 


// Set the last-page number. 
pInfo->SetMaxPage(1) ; 


This code sets the maximum number of pages to print to 1. You’ll learn 
more about the OnPreparePrinting() function later in this chapter. 


Use ClassWizard to add the OnPrint() function to the CDundesvView class, 
as shown in figure 6.35. 
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Fig. 6.35 | 
: : | 
Adding OnPrint() | 
te men ae CDundesview 
CDundes View class. i 
| 
| OnEndPrintPreview 
|) {ID_APP_ABOUT OnFinalRelease o 
| JIDLAPP_EXIT d | OninitisiUpdate 
| JID_FILE MRU_FILE1 OnPrepareDC 
1 JID-FILE -NEW | | OnPreparePrintin 
ID_FILE_OPEN L | 
| [1D_FILE_PRINT _ OnScrof 
| 
L TM Onitemswall ON_ID_ITEMS_WALL:{ 
WW OnLButtonDown ON_WM_LBUTTOND 


W  OnPreparePrinting 


5. Click the Edit Code button and then add the following lines to 
OnPrint(), right after the // TODO: Add your specialized code here 


and/or call the base class comment: 


// Get the printer's horizontal and vertical resolution. 
UINT horDots = pDC->GetDeviceCaps(LOGPIXELSX) ; 
UINT verDots = pDC->GetDeviceCaps(LOGPIXELSY) ; 


// Print the map. 
PrintMap(pDC, horDots, verDots) ; 


These lines retrieve the printer’s resolution and send the dungeon grid 
to the printer. You'll learn more about the OnPrint() function later in 


this chapter. 


6. In the OnPrint() function, comment out the line CView: :OnPrint(pDC, 
pInfo), which calls the base class’s OnPrint() function. Later in the 


chapter, you’ll see why you need to do this. 


7. Add the following function to the end of the DUNDEVW.CPP file: 


void CDundesView::PrintMap(CDC* pDC, 
UINT horDots, UINT verDots) 

{ 
// Get a pointer to the document. 
CDundesDoc* pDoc = GetDocument() ; 


// Calculate sizes for the current device context. 


UINT verOffset = verDots / 2; 
UINT horOffset = horDots / 2; 
UINT verSquareSize = verDots / 5; 
UINT horSquareSize = horDots / 5; 
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// Draw the grid's vertical lines. 
for (int i=; i<=COLSIZE; ++i) 


{ 
UINT x1 = horSquareSize * i + horOffset; 
UINT y1 = verOffset; 
UINT x2 = x1; 
UINT y2 = verSquareSize * COLSIZE + verOffset; 
pDC->MoveTo(x1, y1); 
pDC->LineTo(x2, y2); 
} 


// Draw the grid's horizontal lines. 
for (i=0; i<=ROWSIZE; ++i) 


{ 
UINT x1 = horOffset; 
UINT y1 = verSquareSize * i + verOffset; 
UINT x2 = horSquareSize * ROWSIZE + horOffset; 
UINT y2 = y1; 
pDC->MoveTo(x1, y1); 
pDC->LineTo(x2, y2); 
} 


// Draw the dungeon's objects onto the map. 
for (i=; i<DUNGEONSIZE; ++i) 
{ 
// Get the currently indexed item. 
CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt (i); 


// Create and select a brush for the item. 
WORD item = pItem->iType; 

CBrush* brush = new CBrush(m_Colors[item]) ; 
CBrush* oldBrush = pDC->SelectObject(brush) ; 


// Calculate the pixel coordinates 

// for drawing the square. 

UINT row = i / ROWSIZE; 

UINT col = i (row * ROWSIZE) ; 

UINT x = col horSquareSize + horOffset; 
UINT y = row verSquareSize + verOffset; 


$ ot 


// Draw the square. 
pDC->Rectangle(x, y, x+horSquareSize+1, 
y+verSquareSize+1) ; 


// Restore the DC and delete the brush. 


pDC ->SelectObject(oldBrush) ; 
delete brush; 


} 


This function does the actual printing of the dungeon grid. You'll learn 
more about it later in this chapter. 
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Fig. 6.36 
Viewing items in 
the dungeon grid. 


8. Load the DUNDEVW.H file and add the following function declaration 
to the CDundesView class’s Implementation section, right after the other 
declarations you placed there previously: 


void PrintMap(CDC* pDC, UINT horDots, UINT verDots) ; 


This line declares PrintMap() aS a protected member function of the 
CDundesView Class. 


This completes the final version of Dungeon Designer. To compile the pro- 
gram, select the Project menu’s Build command. Visual C++ then compiles 
and links the application. 


Running Dungeon Designer, Version 6 

When you run the new version of Dungeon Designer, the main window 
looks exactly like the last version’s. Now, however, you can right-click items 
in the dungeon grid to see what they are. For example, if you right-click the 
monster in the top right corner of the grid, you see the message box shown 
in figure 6.36. This message box tells you that the item is a monster with an 
item number of 2 and an item value of 50. 


You can now also print the dungeon grid that’s currently displayed in the 
window. To do this, click the toolbar’s printer icon or select the File menu’s 
Print command. If you were to print the default dungeon layout shown in 
figure 6.36, your printer would produce a sheet like that shown in figure 6.37. 
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Fig. 6.37 

A printout of the 
default dungeon 
layout. 


You might want to print several copies of the default dungeon layout and give them 
to friends who are about to play Aztec Adventure. The printouts make great graph 
paper on which to map each dungeon floor as your friends (or you!) play the game. 
If you're really ambitious, how about adding a command to Dungeon Designer’s 
menu that enables the user to choose whether to print the entire dungeon map or 
print just the walls and doors? Having a map showing only walls and doors would 
make the game easier to play for someone who doesn’t like to map. 


Examining the OnRButtonDown() Function 

As I mentioned previously, the OnRButtonDown() function gets called when- 
ever the user right-clicks inside Dungeon Designer’s main window. This right- 
click indicates that the user wants to see some details about the item stored in 
the grid square on which she clicked. For example, as you saw previously, 
right-clicking the square holding the default monster brings up a message 
box showing the monster’s number and value. All this happens inside 
OnRButtonDown(). 
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First, OnRButtonDown() Calls ClickInsideGrid() inside an if statement in order 
to determine whether the user clicked on the grid or on some other part of 
the window: 


if (ClickInsideGrid(point) ) 


If the click wasn’t on the grid, ClickInsideGrid() returns FALSE and 
OnRButtonDown() does nothing. Otherwise, ClickInsideGrid() returns TRUE, 
and OnRButtonDown() must display the attributes for the square on which the 
user clicked. 


To do this, the program gets a pointer to the document object, which holds 
the data for the dungeon: 


CDundesDoc* pDoc = GetDocument() ; 


Then, the program calculates the item’s index in the m_Dungeon array and 
saves it in the local variable itemNum: 

UINT col = (point.x - OFFSET) / SQUARESIZE; 

UINT row = (point.y - OFFSET) / SQUARESIZE; 

UINT itemNum = row * ROWSIZE + col; 
In order to display the details about the selected item, the program needs a 
string that it can manipulate. It obtains this string by constructing a CString 
object: 


CString s("Type:\t"); 


CString is another of Visual C++’s built-in classes that you can use in your 
programs. This class provides many member functions for manipulating 
strings, without having to use C++’s clumsy string-handling. The preceding 
line creates a CString object containing the string Type: followed by a tab 
character. 


Next, OnRButtonDown() gets a pointer to the item stored in the selected square: 


CItem* pItem = 
(CItem*) pDoc->m_Dungeon.GetAt (itemNum) ; 


The following switch statement adds the appropriate item type to the string: 


switch (pItem->iType) 


{ 
case Empty: += "Empty"; break; 
case Wall: += "Wall"; break; 
case Door: "Door"; break; 


+= "Treasure"; break; 
+= "Monster"; break; 
+= "Key"; break; 


case Treasure: 
case Monster: 
case Key: 


nnna 
+ 
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case Sword: s += "Sword"; break; 

case Armor: s += "Armor"; break; 

case Potion: s += "Potion"; break; 

} 

As you may have realized from the preceding lines, the CString class over- 
loads the += operator so that it concatenates the string stored in the object 
with the string given to the right of the operator. For example, if the item in 
question was a door, after the switch statement, the string would contain the 
text Type: Door, with a tab character between the colon and the word Door. 


By using the concatenation operator again, the string adds the next line of 
text to the string: 


s += "\nNumber:\t"; 


Because the text on the right of the operator starts with a newline character, 
the text will appear on a separate line, even though it’s all contained in a 
single string. 


The program then converts the item’s number to ASCII characters and adds 
those characters to the string object: 
char num[10]; 


itoa(pItem->iNumber, num, 10); 
s += num; 


The item’s value is added to the string in the same way: 


s += "\nValue:\t"; 

itoa(pItem->iValue, num, 10); 

s += num; 
Finally, OnRButtonDown() uses the handy message box to display the string 
containing the item’s attributes: 


MessageBox(s, "Item", MB OK); 


Examining the OnPreparePrinting() Function 

When the user wants to print a document, she selects the File menu’s Print 
command. When she does, the program starts preparing the program to send 
data to the printer. One of the first things required by this preparation is 
displaying the Print dialog box for the user (see fig. 6.38). 


The Print dialog box gives the user a chance to change printer settings, as 
well as choose which pages of a document to print. The Print dialog box is 
displayed by the Cview class’s OnPreparePrinting() function, which you must 
override in your view class. 


243 


244 Chapter 6—Programming Dungeon Designer 


Fig. 6.38 
The Print dialog 
box. 
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In Dungeon Designer, you added only one line of custom code to the 
OnPreparePrinting() function: 


pInfo->SetMaxPage(1); 


This line sets the maximum page number (displayed in the Print dialog box’s 
To box) to 1. Because a dungeon map fits on only one page, it makes no 
sense to allow more pages to be printed. After calling pInfo->SetMaxPage(), 
OnPreparePrinting() calls the base class’s version of the function, which dis- 
plays the Print dialog box and prepares the printer device context, a pointer 
to which is forwarded to the OnPrint() member function. 


Examining the OnPrint() Function 

In a standard AppWizard-generated program, there’s usually no need to over- 
ride the OnPrint() function. The base class’s version simply calls the OnDraw() 
function, sending along the printer DC. This causes OnDraw() to display the 
document’s data on the printer rather than on the application’s window. 


Unfortunately, OnDraw() cannot display a bitmap on a printer, which is ex- 
actly what you need to do in Dungeon Designer. To print the dungeon lay- 
out, then, you must short-circuit the normal printing functions by overriding 
OnPrint(). 


The overridden OnPrint() function first determines the resolution of a page 
for the current printer: 


UINT horDots 
UINT verDots 


pDC ->GetDeviceCaps (LOGPIXELSX) ; 
pDC ->GetDeviceCaps(LOGPIXELSY) ; 


oil 


The program gets the horizontal resolution by calling the DC object’s 
GetDeviceCaps() function with the argument LOGPIXELSX. (The pDc pointer is 
passed in as one of OnPrint()’s parameters.) Calling the same function with 
LOGPIXELSY gets the vertical resolution of a page. 
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GetDeviceCaps() is a CDC class version of a Windows API function of the same 
name. You can use it to obtain all kinds of information about a device context, 
depending on the value of its single argument. For example, the function call 
GetDeviceCaps (PLANES) returns the number of color planes used by the DC, 
whereas GetDeviceCaps (NUMCOLORS) returns the number of colors in the DC’s 
color table. Refer to your Visual C++ documentation for more information. 


After determining the page’s resolution for the printer, OnPrint() calls the 
PrintMap() function to actually print the dungeon grid: 


PrintMap(pDC, horDots, verDots) ; 


You may remember that, in OnPrint(), you commented out the call to the 
base class’s OnPrint() function. You had to do this because the base class’s 
OnPrint() function calls OnDraw() to print the current page of the document. 
If you forget to comment out this line, you’ll end up with a printout that 
looks like figure 6.39. The grid is printed fine by PrintMap(), but then 
OnDraw() tries to print the bitmap, and you end up with a black rectangle 

on your printout. 


Fig. 6.39 

The OnDraw() 
function produces 
a black rectangle 
when it tries to 
print a bitmap. 
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Examining the PrintMap() Function 

To send the dungeon grid to the printer, OnPrint() calls the PrintMap() func- 
tion, which not only calls the GDI functions necessary to create the dungeon 
grid’s image, but also scales the image based on the printer’s horizontal and 
vertical resolutions. 


PrintMap()’s three parameters are the DC on which to draw the dungeon-grid 
image, and the horizontal and vertical resolution of the page, based on dots 
per inch. 


Because PrintMap() must access the m_Dungeon array, the program first needs 
to get a pointer to the document object: 


CDundesDoc* pDoc = GetDocument() ; 


The program then calculates some values it needs to scale the image based on 
the page’s resolution: 

UINT verOffset = verDots / 2; 

UINT horOffset = horDots / 2; 


UINT verSquareSize = verDots / 5; 
UINT horSquareSize = horDots / 5; 


The verOffset and horOffset local variables are the position on the page at 
which the dungeon grid should be printed. Because these values are calcu- 


lated by dividing the vertical and horizontal dots-per-inch by 2, the top left 
corner of the grid will end up one-half inch from the left and top of the page. 


The verSquareSize and horSquareSize variables represent the size of a single 
square in the grid. Because these values are calculated by dividing the vertical 
and horizontal dots-per-inch by 5, each square will be one-fifth of an inch on 
each side. 


In the first for loop, the program draws the grid’s vertical lines: 


for (int i=0; i<=COLSIZE; ++i) 


{ 
UINT x1 = horSquareSize * i + horOffset; 
UINT y1 = verOffset; 
UINT x2 = x1; 
UINT y2 = verSquareSize * COLSIZE + verOffset; 


pDC ->MoveTo(x1, y1); 
pDC->LineTo(x2, y2); 


Creating Dungeon Designer, Version 6 


In the loop, the X and Y coordinates for each end of a line are calculated 
using the horOffset, horSquareSize, verOffset, and verSquareSize variables. 
This scales the lines based on the current printer’s resolution, ensuring that 
the lines will be the same size on any printer. Then a call to the DC’s 
MoveTo() and LineTo() member functions draws the actual line. 


The grid’s horizontal lines are drawn in a similar manner, using another for 
loop: 


for (i=; i<=ROWSIZE; ++i) 


{ 
UINT x1 = horOffset; 
UINT yi = verSquareSize * i + verOffset; 
UINT x2 = horSquareSize * ROWSIZE + horOffset; 
UINT y2 = y1; 
pDC->MoveTo(x1, y1); 
pDC->LineTo(x2, y2); 
} 


Next, PrintMap() must draw the items that belong in each square of the grid. 
This means iterating through the m_Dungeon array with yet another for loop: 


for (i=0; i<DUNGEONSIZE; ++i) 


Inside the loop, the program first gets a pointer to the next item in the 
m_Dungeon array: 


CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt (i) ; 


Then, the program creates a brush of the right color for the item and selects 
the brush into the DC: 
WORD item = pItem->iType; 


CBrush* brush = new CBrush(m_Colors[item]) ; 
CBrush* oldBrush = pDC->SelectObject (brush); 


Before actually drawing the square, the program must calculate the square’s 
coordinates on the page: 

UINT row i / ROWSIZE; 

UINT col i - (row * ROWSIZE) ; 


UINT x = col * horSquareSize + horOffset; 
UINT y = row * verSquareSize + verOffset; 


Then, a call to the DC’s Rectangle() member function draws the item on the 
grid: 


pDC->Rectangle(x, y, x+horSquareSizet+1, 
ytverSquareSizet1) ; 
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Finally, the old brush is selected back into the DC, freeing up the new brush 
so that it can be deleted: 

pDC ->SelectObject(oldBrush) ; 

delete brush; 


After the loop ends, all 1,024 items will have been drawn on the dungeon 
grid, at which point the image is sent to the printer. 


The Listings 


Following are the complete listings for the files in the Dungeon Designer 
project that you modified over the course of this chapter. In these listings, 
code that you added manually is shown between double lines of slash charac- 
ters. Code that you added using ClassWizard is listed normally—that is, it is 
not shown between double lines of slash characters. Files that were created by 
AppWizard, but which you did not modify, are not shown here. If you’d like 
to know what the unlisted files contain, load them from disk using Visual 
C++ or some other text editor. 


Listing 6.1 DUNDES.H—Header File for the CDundesApp Class 


// dundes.h : main header file for the DUNDES application 
// 


#ifndef _ _AFXWIN_H_ _ 
#error include ‘stdafx.h' before including this file for PCH 
#endif 


#include "“resource.h" // main symbols 


TILITITITTTTTT TTT TTT TTT TT 
[ILILILILIL 
// START CUSTOM CODE 

VITET AAAA NAA TIIE TE AAA 
TILTTTTITTTTTT TTT TTT TTT TTT TT 


enum {Empty, Wall, Door, Key, Monster, 
Treasure, Sword, Armor, Potion }; 


const SQUARESIZE = 12; 
const ROWSIZE = 32; 
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const COLSIZE = 32; 
const OFFSET = 2; 
const DUNGEONSIZE = 1024; 


struct CItem 


WORD iType; 

WORD iNumber; 

WORD iValue; 
J; 


[IIIIIIIII IIIT 
FILTTTTTTTTT IIIA 
// END CUSTOM CODE 

[IIILIILIIIII IIIT 
[IIIIII III TTT TATA TL 


FULTTTTTTTT TTA TATA AAT ATTA ATA AAA ATT TL 
// CDundesApp: 

// See dundes.cpp for the implementation of this class 

// 


class CDundesApp : public CWinApp 
{ 
public: 

CDundesApp() ; 


// Overrides 
// ClassWizard generated virtual function overrides 
/ /{{AFX_VIRTUAL (CDundesApp) 
public: 
virtual BOOL InitInstance() ; 
/ /}}AFX_VIRTUAL 


// Implementation 


//{{AFX_MSG(CDundesApp) 
afx_msg void OnAppAbout() ; 
// NOTE - the ClassWizard will add and remove member 
// functions here. 
// DO NOT EDIT what you see in these blocks of generated code! 
//}}AFX_MSG 
DECLARE_MESSAGE_MAP ( ) 


J}; 
[ILILILILIL IIIA 
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Listing 6.2 MAINFRM.CPP—Implementation File for the 


CMainFrame Class 


// mainfrm.cpp : implementation of the CMainFrame class 
// 


#include "stdafx.h" 
#include "dundes.h" 


#include "mainfrm.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED CODE THIS _FILE[] = _ _FILE_ _; 
#endif 


TIANI AAAA AAAA ANINA ANATS TAA ATA AAT A TIEI ECA 
// CMainFrame 


IMPLEMENT_DYNCREATE (CMainFrame, CFrameWnd) 


BEGIN_MESSAGE_MAP (CMainFrame, CFrameWnd) 
//{{AFX_MSG_MAP (CMainFrame) 
// NOTE - the ClassWizard will add and remove mapping 
// macros here. 
// DO NOT EDIT what you see in these blocks of generated code! 
ON_WM_CREATE ( ) 
//}}AFX_MSG_MAP 
END_MESSAGE_MAP( ) 


FULTIITITTTTTT TTT TTT TTT ATT TTT TTT ATA AAT AL 
// arrays of IDs used to initialize control bars 


// toolbar buttons - IDs are command buttons 


FILTTTTTTTTT TTT TTT TTT TTT TTT 
LISTINI AT C AAN TTT TTT 
// START CUSTOM CODE 

LILAA TATEA CELTA TATA TTT 
TILTTTTTTTTT TTT TTT TTT TTT TTT 


static UINT BASED_CODE buttons[] = 
{ 

// same order as in the bitmap ‘toolbar.bmp' 

ID_FILE_NEW, 

ID_FILE_OPEN, 

ID_FILE_SAVE, 

ID_FILE_PRINT, 

ID_SEPARATOR, 

ID_ITEMS WALL, 

ID_ITEMS_DOOR, 

ID_ITEMS_ MONSTER, 

ID_ITEMS_TREASURE , 

ID_ITEMS_KEY, 

ID_ITEMS_SWORD, 


}; 


The Listings 


ID_ITEMS_ARMOR, 

ID_ITEMS POTION, 
ID_SEPARATOR, 

ID_APP_ABOUT, 


TITTTTTTTTT TTT TTT TTT ATTA TAAL 
[IILIIIIII IILI 
// END CUSTOM CODE 

[IIIIIIIII ILILILILIL 
[ILILILILIL LIIATI 


PILULTTT LTT ATTA AAA AT AAA AAA AAA AAA TT TTT 
// CMainFrame construction/destruction 


CMainFrame: :CMainFrame() 


} 


// TODO: add member initialization code here 


CMainFrame: :~CMainFrame() 


{ 
} 


int CMainFrame: :OnCreate(LPCREATESTRUCT lpCreateStruct) 


{ 


if (CFrameWnd::OnCreate(1lpCreateStruct) == -1) 
return -1; 


if (!m_wndToolBar.Create(this) || 
!m_wndToolBar.LoadBitmap(IDR_MAINFRAME) |; 
!m_wndToolBar.SetButtons (buttons, 
sizeof (buttons) /sizeof (UINT) ) ) 


TRACE@("Failed to create toolbar\n") ; 
return -1; // fail to create 
} 


// TODO: Delete these three lines if you don't want the toolbar 
// to be dockable 

m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY) ; 
EnableDocking(CBRS_ALIGN_ANY) ; 

DockControlBar (&m_wndToo1Bar) ; 


// TODO: Remove this if you don't want tool tips 
m_wndToolBar .SetBarStyle(m_wndToolBar.GetBarStyle() ! 
CBRS_TOOLTIPS | CBRS_FLYBY); 


return 0; 


(continues) 
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Listing 6.2 Continued 


PIALI TALII ATTA TAA TAA AA AAA AT EII 
// CMainFrame diagnostics 


#ifdef _DEBUG 
void CMainFrame: :AssertValid() const 


{ 
CFrameWnd: :AssertValid() ; 
} 
void CMainFrame: :Dump(CDumpContext& dc) const 
{ 
CFrameWnd: :Dump(dc) ; 
} 


#endif //_DEBUG 


VIALIS TANINI ATTA TTT AAA AAA AAA AAA ATL 
// CMainFrame message handlers 


BOOL CMainFrame: :PreCreateWindow(CREATESTRUCT& cs) 

{ 
// TODO: Add your specialized code here and/or call the base 
// class 


[IILI ITIITI 
[I/III IITIN 
// START CUSTOM CODE 

TIPTITTTTTTTTT TTT TTT TTT ATT TTT 
[ILILILILIL 


cs.cx 
cs.cy 


402; 
470; 


LISAA TEIA AAA INASI ALIAT A EAA 
CIIILE LATINAS IINE ATT 
// END CUSTOM CODE 

[IIIIIIIIIII IIIA 
LULILO AALA AAA 


return CFrameWnd: :PreCreateWindow(cs) ; 


Listing 6.3 DUNDEDOC.H—Header File for the CDundesDoc Class 


// dundedoc.h : interface of the CDundesDoc class 
// 
TILTITTTT ITT TTT TTT TTT ATTA AAA AAA A AAA 


class CDundesDoc : public CDocument 

{ 

protected: // create from serialization only 
CDundesDoc(); 
DECLARE_DYNCREATE (CDundesDoc) 


// Attributes 
public: 


[ILIITA I IIIA 
[ILILILILIL 
// START CUSTOM CODE 

TITTTLTTTTT TTT TTT TATA TAT IAA 
CIIILE IAA LEA TET EILIA 


CPtrArray m_Dungeon; 


TITTTTTTTTTTT TTT TTT TTT TTT 
VIFTE TUI IAAL TATAIA ETIS AAEE 
// END CUSTOM CODE 

TITTTTTTTTTTTT TTT TTT TATA TAT TL 
CLIII TTA TTT TATA TTT TTL 


// Operations 
public: 


// Overrides 
// ClassWizard generated virtual function overrides 
//{{AFX_VIRTUAL (CDundesDoc ) 
public: 
virtual BOOL OnNewDocument() ; 
virtual void DeleteContents() ; 
/ /}}AFX_VIRTUAL 


// Implementation 
public: 
virtual ~CDundesDoc(); 


virtual void Serialize(CArchive& ar); // overridden for 
// document i/o 


#ifdef _DEBUG 

virtual void AssertValid() const; 

virtual void Dump(CDumpContext& dc) const; 
#endif 


protected: 


IILL AINIS IAAI TAT 
LEIATU TATIANE CETATEA EEEE 
// START CUSTOM CODE 

TITTTTTTTTTTTT TTT TTT TTT TTT 
[ILILILILIL 


(continues) 
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Listing 6.3 Continued 


BOOL InStartingWalls(int squareNum) ; 


ELIITTI IATE IITE TAA TTT TL 
[ILII IIIN 
// END CUSTOM CODE 

[IILI III IIIT 
[ILILILILIL IIIT 


// Generated message map functions 
protected: 
/ /{{AFX_MSG (CDundesDoc) 
// NOTE - the ClassWizard will add and remove member 
// functions here. 
// DO NOT EDIT what you see in these blocks of generated code! 
//}}AFX_MSG 
DECLARE_MESSAGE_MAP() 
}; 


TUSCIA AAAA IAA EAIA TTT TATA AAEL 


Listing 6.4 DUNDEDOC.CPP—Implementation File for the 
CDundesDoc Class 


// dundedoc.cpp : implementation of the CDundesDoc class 


#include "“stdafx.h" 
#include "dundes.h" 


#include "dundedoc.h" 


#ifdef _DEBUG 

#undef THIS_FILE 

static char BASED CODE THIS _FILE[] = _ _FILE_ _; 
#endif 


TILTTTTTT TTT TTT ATT AAT TTT TTT ATT 
// CDundesDoc 


IMPLEMENT_DYNCREATE (CDundesDoc, CDocument) 


BEGIN _MESSAGE_MAP(CDundesDoc, CDocument) 
/ /{{AFX_MSG_MAP (CDundesDoc) 
// NOTE - the ClassWizard will add and remove mapping 
// macros here. 
// DO NOT EDIT what you see in these blocks of generated code! 
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/ /}}AFX_MSG_MAP 
END_MESSAGE_MAP() 


PELLLTITTT TATA TATA AAA ATTA AAT AT TTL 
// CDundesDoc construction/destruction 


CDundesDoc: :CDundesDoc() 


{ 
// TODO: add one-time construction code here 
} 
CDundesDoc: :~CDundesDoc() 
{ 
} 


BOOL CDundesDoc: :OnNewDocument() 
{ 
if (!CDocument: :OnNewDocument() ) 
return FALSE; 


// TODO: add reinitialization code here 
// (SDI documents will reuse this document) 


FTTTTTTTTT TTT CEN ALATI FEAA CATAT 
/[IIIIIIIIIIII ILLIA 
// START CUSTOM CODE 

LILTITTTTTTTT TTT TT TATA AAA TA TL 
FITTTTTTTTTTT TTT TAT ATTA ATA TAAL 


// Iterate through each square in the dungeon. 

for (UINT i=@; i<DUNGEONSIZE; ++i) 

{ 
// Construct a new item for the current square. 
CItem* pItem = new CItem; 


// If the square must contain a wall... 
if (InStartingWalls(i) ) 


{ 
pItem->iType = Wall; 
pItem->iNumber = Q; 
pItem->iValue = Q; 

} 


// If the square must contain the level's exit... 
else if (i == 61) 


{ 
pItem->iType = Door; 
pItem->iNumber = 5; 
pItem->iValue = Q; 

} 


// If the square must contain 
// the level's boss monster... 
else if ( i == 62) 


(continues) 
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Listing 6.4 Continued 


} 


{ 
pItem->iType = Monster; 
pItem->iNumber = 2; 
pItem->iValue = 50; 

} 


// Otherwise, the square is empty... 

else 

{ 
pItem->iType = Empty; 
pItem->iNumber = 0; 
pItem->iValue = Q; 

} 


// Add the new item to the array. 
m_Dungeon.Add(pItem) ; 


TISUI TITIS AAA EAIA ETA 
[ILILILILIL 
// END CUSTOM CODE 

CIIISEAN TEA AAAA AII TTT TL 
POIL NIINI AEETI EEA TEEI 


return TRUE; 


} 


TICIANE IELA TAAAC ATA TATA TA TT 
// CDundesDoc serialization 


void CDundesDoc: :Serialize(CArchive& ar) 


{ 


if (ar.IsStoring() ) 


{ 


// TODO: add storing code here 


LIITT TITTI CE ATTA TATA TA 
LILAA IATL TTT TTT TTT TATA TTT 
// START CUSTOM CODE 

LISAAINETE EAA TTT ATTA 
IILAN EEIT NIAAA AAA E ATE 


// Iterate through each dungeon square, sending 
// its contents to the output stream. 
for (UINT i=0; i<DUNGEONSIZE; ++i) 
{ 
CItem* pItem = (CItem*) m_Dungeon.GetAt (i) ; 
ar << pItem->iType; 
ar << pItem->iNumber; 
ar << pItem->iValue; 


[ILILILILIL 
TIIA IIASA NITEL IEEE IA T 
// END CUSTOM CODE 

POSIATE CITEA TL 
[ILILILILIL IIIA 


else 
// TODO: add loading code here 


TTTTTTTTTTTT TATA TTA TAA TT 
[ILILILILIL 
// START CUSTOM CODE 

[ILILILILIL 
TTTTTITTTTTT ILAT LAATII 


// Iterate through each dungeon square, 
// loading its contents from the input stream. 
for (UINT i=@; i<DUNGEONSIZE; ++i) 
{ 
CItem* pItem = new CItem; 
ar >> pItem->iType; 
ar >> pItem->iNumber; 
ar >> pItem->iValue; 
m_Dungeon.Add(pItem) ; 
} 


// Tell the view to update its display. 
UpdateAllViews (NULL); 


[ILILILILIL IIIN 
[ILILILILIL 
// END CUSTOM CODE 

TITTTTTTTTTTT TTT TATA ATTA TATA TTT 
FTLTTTTTTTTTT TTT TTA TATA TTA TAA TAA 


} 


[11111111L TTT TTT ATTA TTA TAT 
// CDundesDoc diagnostics 


#ifdef _DEBUG 
void CDundesDoc::AssertValid() const 


{ 
CDocument: :AssertValid() ; 


} 

void CDundesDoc: :Dump(CDumpContext& dc) const 
: CDocument: :Dump(dc) ; 

‘ena / /_DEBUG 


(continues) 
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Listing 6.4 Continued i 


TITTTLTTTTTI TTT TTT TTT TATA AAA AAA A I 
// CDundesDoc commands 


void CDundesDoc: :DeleteContents() 

{ 
// TODO: Add your specialized code here and/or call the base 
// class 


[IIIT TTT TTT TTT TTT 
FTTTTTTTTTTTT TTT TTT TATA TAT TT 
// START CUSTOM CODE 

TITTTTITTTTTT TTT TTT TTT TTT TTT 
TILILA TETEA TINCER TLT EATI 


// Get the size of the array. 
UINT size = m_Dungeon.GetSize(); 


// If the array contains pointers, delete the 
// pointers and empty the array. 
if (size > 0) 
{ 
for (UINT i=@; i<DUNGEONSIZE; ++i) 
delete m_Dungeon.GetAt(i) ; 
m_Dungeon.RemoveA11(); 
} 


LIILIA 
TITTTTTTITTTT TTT TTT TTT ATTA TTT 
// END CUSTOM CODE 

TITTTTTTTTTTT TTT TATA TTT ATA TT 
LILIAN A TTT ATA ATT 


CDocument: :DeleteContents() ; 


} 


FILTTTTITTTTIT TTT TTT TTT TTT TT 
FITTTTTTTTTT TTT TTT TTT TTT TTT 
// START CUSTOM CODE 

ITILIE EAIA TAT TATA CICA AT 
TEELT AAAI TTT EAIA TA 


BOOL CDundesDoc: :InStartingWalls(int squareNum) 
{ 
// Determine whether the square is one of 
// the default wall squares. 
if ((squareNum > -1) && (squareNum < ROWSIZE) ) 
return TRUE; 
if ((squareNum > (COLSIZE-1)*ROWSIZE) && 
(squareNum < COLSIZE*ROWSIZE) ) 
return TRUE; 
if ((squareNum % ROWSIZE == @) {| 
(squareNum % ROWSIZE == ROWSIZE-1) ) 
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return TRUE; 
if ((squareNum == 93) |; (SquareNum == 94) ) 
return TRUE; 
return FALSE; 
} 


[IIIIIIIIII III IIIA 
PLIIT CINTAT IA ATIII AEEA TT 
// END CUSTOM CODE 

FLLTLLTTTT TTT IIIA 
FLLTTTTTTTT TALL TTA TTT TATA TAA AAA 


a 


Listing 6.5 DUNDEVW.H—Header File for the CDundesView Class 


// dundevw.h : interface of the CDundesView class 
// 
FICELIIPVINA LATESAN EINAT ALATA TAA IIE TL 


class CDundesView : public CView 

{ 

protected: // create from serialization only 
CDundesView() ; 
DECLARE_DYNCREATE (CDundesView) 


// Attributes 
public: 
CDundesDoc* GetDocument() ; 


FITTTTTTLTTTT TTT ATTA TAA AAA TTT 
[ILILILILIL AIIIN 
// START CUSTOM CODE 

[ILILILILIL IILI 
[IIIIIIIIIII IIIA 


protected: 
int m_mode; 
CBitmap* m_pBitmap; 
COLORREF m_Colors[9]; 


FITTTTTTTTTT TATA TATA AAT TTT 
LIECIT AINAANI TAALA ATH 
// END CUSTOM CODE 

FITTTLTTLTTT TTT TATA ATA ATT TTT 
[ILILILILIL TTT TTT TAT TAA ATTA AAT TAAL 


// Operations 
public: 


// Overrides 
// ClassWizard generated virtual function overrides 
/ /{{AFX_VIRTUAL (CDundesView) 
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Listing 6.5 Continued 


public: 
virtual void OnDraw(CDC* pDC); // overridden to draw this view 
protected: 
virtual BOOL OnPreparePrinting(CPrintInfo* pInfo); 
virtual void OnBeginPrinting(CDC* pDC, CPrintInfo* pInfo); 
virtual void OnEndPrinting(CDC* pDC, CPrintInfo* pInfo); 
virtual void OnUpdate(CView* pSender, LPARAM lHint, 
CObject* pHint) ; 

virtual void OnPrint(CDC* pDC, CPrintInfo* pInfo); 
//}}AFX_VIRTUAL 

// Implementation 

public: 
virtual ~CDundesView(); 


#ifdef _DEBUG 


virtual 
virtual 
#endif 


protected: 


void AssertValid() const; 
void Dump(CDumpContext& dc) const; 


TITTTITTTTTTTTT TTT TTT TATA AAT 
II/III TTT TT TATA TL 
// START CUSTOM CODE 

[IIIT IINITAN 
ILILILILIL 


void DrawGrid(CDC* dc); 

BOOL ClickInsideGrid(CPoint point); 

BOOL InStartingWalls(int squareNum) ; 

void HandleLeftClick(UINT squareNum, UINT col, UINT row); 
void PlaceWall(CItem* pItem, UINT x, UINT y); 

void PlaceItem(CItem* pItem, UINT x, UINT y, UINT mode); 
BOOL NotValidItem(CItem* pItem) ; 

BOOL FindItem(WORD itemType, WORD itemNum, WORD& itemValue) ; 
void DrawSquare(UINT x, UINT y, CBrush* brush) ; 

void PrintMap(CDC* pDC, UINT horDots, UINT verDots) ; 


FAATINO LEEN 
LEI LEIA CEEA ATILE EAA A 
// END CUSTOM CODE 

VAASI TALN AIAC EMIEI TTT 
TITTTITTTTTTT TTT TTT TTT TATA ATT 


// Generated message map functions 


protected: 


//{{AFX_MSG(CDundesView) 


afx_msg 
afx_msg 
afx_msg 
afx_msg 


void OnItemsArmor() ; 

void OnUpdateItemsArmor (CCmdUI* pCmdUI) ; 
void OnItemsDoor(); 

void OnUpdateItemsDoor (CCmdUI* pCmdUI) ; 
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afx_msg void OnItemsKey() ; 

afx_msg void OnUpdateItemsKey(CCmdUI* pCmdUT) ; 

afx_msg void OnItemsMonster() ; 

afx_msg void OnUpdateItemsMonster(CCmdUI* pCmdUT) ; 
afx_msg void OnItemsPotion() ; 

afx_msg void OnUpdateItemsPotion(CCmdUI* pCmdUT) ; 
afx_msg void OnItemsSword() ; 

afx_msg void OnUpdateItemsSword(CCmdUI* pCmdUT) ; 
afx_msg void OnItemsTreasure() ; 

afx_msg void OnUpdateItemsTreasure(CCmdUI* pCmdUT) ; 
afx_msg void OnItemsWall1(); 

afx_msg void OnUpdateItemsWall(CCmdUI* pCmdUT) ; 
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct) ; 
afx_msg void OnLButtonDown(UINT nFlags, CPoint point); 
afx_msg void OnRButtonDown(UINT nFlags, CPoint point); 
/ /}}AFX_MSG 

DECLARE_MESSAGE_MAP() 


F; 


#ifndef _DEBUG // debug version in dundevw.cpp 
inline CDundesDoc* CDundesView: :GetDocument () 

{ return (CDundesDoc*)m_pDocument; } 
#endif 


TISIVIALIA ATINI TTT TTT TTT TATA TATA TAA TTT 


Listing 6.6 DUNDEVW.CPP—Implementation File for the 
CDundes View Class 


// dundevw.cpp : implementation of the CDundesView class 
// 


#include "stdafx.h" 
#include "dundes.h" 


#include "dundedoc.h" 
#include "dundevw.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED_CODE THIS FILE[] = _ _FILE__; 
#endif 


[ILII III TTT TTT ATTA TAA TAA TTL 
FITITTTTTTTTT TTT TTA EITE 
// START CUSTOM CODE 

FITTTTTTTTTTTT TATA TATA TAT TTT TTT 
[IILI I TTT TATA ATT TT 
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Listing 6.6 Continued 


#include "“itemdlg.h" 


TILTTITITTTTTT TTT TTT TATA TATA TT 
LELEA AT TATIE LERIA I. 
// END CUSTOM CODE 

MINILE ET TTT TTT TTT TTT ATT 
VAA ETAETA NIAAA ILAA TATA TTT TT 


FIILIS TTT ATT AAEL 
// CDundesView 


IMPLEMENT_DYNCREATE(CDundesView, CView) 


BEGIN_MESSAGE_MAP(CDundesView, CView) 


//{{AFX_MSG_MAP (CDundesView) 

ON_COMMAND(ID_ITEMS_ARMOR, OnItemsArmor ) 
ON_UPDATE_COMMAND_UI(ID_ITEMS_ARMOR, OnUpdateItemsArmor ) 
ON_COMMAND(ID_ITEMS_DOOR, OnItemsDoor) 
ON_UPDATE_COMMAND_UI(ID_ITEMS_DOOR, OnUpdateItemsDoor) 
ON_COMMAND(ID_ITEMS_KEY, OnItemsKey) 
ON_UPDATE_COMMAND_UI(ID_ITEMS_KEY, OnUpdateItemsKey ) 
ON_COMMAND(ID_ITEMS_ MONSTER, OnItemsMonster) 
ON_UPDATE_COMMAND_UI(ID_ITEMS_ MONSTER, OnUpdateItemsMonster) 
ON_COMMAND(ID_ITEMS_POTION, OnItemsPotion) 
ON_UPDATE_COMMAND_UI(ID_ITEMS_POTION, OnUpdateItemsPotion) 
ON_COMMAND(ID_ITEMS_SWORD, OnItemsSword) 
ON_UPDATE_COMMAND_UI(ID_ITEMS_SWORD, OnUpdateItemsSword) 
ON_COMMAND(ID_ITEMS_ TREASURE, OnItemsTreasure) 
ON_UPDATE_COMMAND_UI(ID_ITEMS_TREASURE, OnUpdateItemsTreasure) 
ON_COMMAND(ID_ITEMS_WALL, OnItemsWal1l) 
ON_UPDATE_COMMAND_UI(ID_ITEMS_ WALL, OnUpdateItemsWal1) 
ON_WM_CREATE ( ) 

ON_WM_LBUTTONDOWN ( ) 

ON_WM_RBUTTONDOWN ( ) 

/ /}}AFX_MSG_MAP 

// Standard printing commands 

ON_COMMAND(ID_FILE_PRINT, CView: :OnFilePrint) 
ON_COMMAND(ID_FILE_PRINT_PREVIEW, CView: :OnFilePrintPreview) 


END_MESSAGE_MAP( ) 


FITLTTTTTTTT AAAA TTT TTT TATA 
// CDundesView construction/destruction 


CDundesView: :CDundesView( ) 


{ 


// TODO: add construction code here 


VINILI TITIA T TAT TTT EEA 
CSILLA EECA ETI TETTA 
// START CUSTOM CODE 

[ILILILILIL 
PIATI ANI INTIA AAAA 
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m_mode = Wall; 

m_Colors[Empty] = RGB(255,255, 255) ; 
m_Colors[Wall] RGB(128,128,128) ; 
m_Colors[Door] RGB (0,0,255); 
m_Colors[Key] = RGB(255,255,0); 
m_Colors[Monster] = RGB(255,0,0); 
m_Colors[Treasure] = RGB(0,128,0); 
m_Colors[Sword] RGB(255,0,255) ; 
m_Colors[Armor] RGB(@, 255,255) ; 
m_Colors[Potion] = RGB(@,255,0); 


IAIL ATATIA IAL AT AEA 

TAFITI ANA AAAA TTA TTT TTL 

// END CUSTOM CODE 

IAAT AAAA AA OLAITAN 

TAFEA IAA ILIAN ECEE ATELA 
} 


CDundesView: :~CDundesView() 

{ 
IAILIA VIAAL IITE A ITCRA AAT 
IELI LALAA INACTIV IIIENA 
// START CUSTOM CODE 
IEIALELN ELLAN AETA AALI TTT 
SEINALETAN AIALL ANTEA 


delete m_pBitmap; 


TITTTTTTTTTTTT TTT ATTA TATA ATTA TT 

TITTTTTTTTTTT TTT TTT TTT LTTE 

// END CUSTOM CODE 

TITTTTTITTTTTTT TTT TTT TAT TTA TTT TTT 

VINUTIA ALITILIA ATTA TTT 
} 


PIANTAN AAA AA TANAL TTT AAAA TAIAN L AAA TTT ATTA AT ATTA A TT 
// CDundesView drawing 


void CDundesView: :OnDraw(CDC* pDC) 

{ 
CDundesDoc* pDoc = GetDocument() ; 
ASSERT_VALID(pDoc) ; 


// TODO: add draw code for native data here 


VALLANIA AA TTT TATA EALA ATT 
CACAL AAAA TTT TTT TTT TTT ATT 
// START CUSTOM CODE 

CIFT TA TATA TTT 
VIVILI IAAT EATE AAA 
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Listing 6.6 Continued 


// Create a memory DC that's compatible 
// with the paint DC. 

CDC memDC; 
memDC.CreateCompatibleDC(pDC) ; 


// Select the bitmap into the memory DC. 
memDC.SelectObject(m_pBitmap) ; 


// Blit the bitmap onto the screen. 
pDC->BitB1t(@, ©, 640, 480, &memDC, ©, ©, SRCCOPY) ; 


TILTTTITTTTIT TTT TATA AA FEE E. 
ILIACA ELCA TAT EEA ECEAT 
// END CUSTOM CODE 

/IIIIIIIIII IIIT 
/[/IIIIIIII III IIIN 


} 


LIIALLINEN AATAL AL A TTT 
// CDundesView printing 


BOOL CDundesView: :OnPreparePrinting(CPrintInfo* pInfo) 


{ 
// default preparation 


TITTTTTTTTTTTTT TTT TATA L 
(LIALTAT AELA A UAIN. 
// START CUSTOM CODE 

[IIIILIIIIII IIIA 
TILTITITITTTT TTT TATA TTA 


// Set the last-page number. 
pInfo->SetMaxPage (1) ; 


TITITTTTTTTTT TT TTT TATA TAT TT 
FITITTTTTTTTT TTT TTT TTT TTT TT TAL 
// END CUSTOM CODE 

[I/III II IIIT 
TILTTTTTTTTTTT TTT TTT TATA ATTA TTL 


return DoPreparePrinting(pInfo) ; 


} 


void CDundesView: :OnBeginPrinting(CDC* /*pDC*/, CPrintInfo* /*pInfo*/) 


{ 
// TODO: add extra initialization before printing 


} 


void CDundesView: :OnEndPrinting(CDC* /*pDC*/, CPrintInfo* /*pInfo*/) 
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{ 
// TODO: add cleanup after printing 


} 


FULTITTTTTTTTT TTT TTT TTT TATA AAA ATA 
// CDundesView diagnostics 


#ifdef _DEBUG 
void CDundesView: :AssertValid() const 


{ 
CView: :AssertValid() ; 
} 
void CDundesView: :Dump(CDumpContext& dc) const 
{ 
CView: :Dump(dc) ; 
} 


CDundesDoc* CDundesView: :GetDocument() // non-debug version is inline 
{ 

ASSERT (m_pDocument ->IsKindOf (RUNTIME_CLASS(CDundesDoc) ) ) ; 

return (CDundesDoc*)m_pDocument; 


} 
#endif //_DEBUG 


TITTITITTTTTTTT TTT TTT TTT TTT ATTA TATA ATTA AA A A 
// CDundesView message handlers 


void CDundesView: :OnItemsArmor () 


{ 
// TODO: Add your command handler code here 


FLTTTTTTTTTTTT TTT TATA TTT TTT 
CEILI IALA TTT TTT TTT TA TTT TT 
// START CUSTOM CODE 

VIOLATA LIA AAI LAAI 
AUNLI EEE TEADA 


m_mode = Armor; 


TTTTTTTTTTTT TTT NIITIT 

TITTTTTITTTTTT TTT TTT TATA TTT TTT 

// END CUSTOM CODE 

CEIC AATA ATTA TA TTT IA 1 

PILIAN IAA ALIATE A CEAT IAEA AA 
} 


void CDundesView: :OnUpdateItemsArmor (CCmdUI* pCmdUI) 


{ 
// TODO: Add your command update UI handler code here 


LIALTAT EAA ACLA Id 
TIULTITTTTTTTT TTT TAT ATTA TTT 
// START CUSTOM CODE 

[ILILILILIL IIIA 
FTLTTTTTTTTTT TTT TTA TTT TTT TATA 
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Listing 6.6 Continued 


if (m_mode == Armor) 

pCmdUI ->SetCheck (TRUE) ; 
else 

pCmdUI ->SetCheck (FALSE) ; 


SIATA IANI A TIDA TEE TT 

[IIIIIIIIIII III IIIT 

// END CUSTOM CODE 

[III IIIA IIIT 

/[IIIIIIIIIIIII IIIA 
} 


void CDundesView::0nItemsDoor() 


{ 
// TODO: Add your command handler code here 


[IIILII II III IILAN 
ILILILILIL AT AAA EAT 
// START CUSTOM CODE 

[IIIIIIIIIIII TTT TTT TTT ATTA TT 
TIAE EAA IA ATTA TAA TAT 


m_mode = Door; 


/IIIIIIII III TTT TTT TATA AAT TTT 

FILTTTTTTTTTTT TTT TTT ATA TA 

// END CUSTOM CODE 

FILITTTTTTTTT ATTA TATA TTT 

[IIIILI IILI TTT TTT TATA ATA 
} 


void CDundesView: :OnUpdateItemsDoor (CCmdUI* pCmdUTI) 


{ 
// TODO: Add your command update UI handler code here 


CAVILAT ACEA TELA 
TIPLIITTTTTTTT TTA TTT TTA AAT 
// START CUSTOM CODE 

TUUINA TALAAN TTT AAT TTT 
CITITAN INTAN TTT TTT TATAI TTT 


if (m_mode == Door) 

pCmdUI ->SetCheck (TRUE) ; 
else 

pCmdUI ->SetCheck (FALSE) ; 


} 


ALITILIA ATAA A PU AIA ATA 
[I/III III I III IIIA 
// END CUSTOM CODE 

TILIAN EIA TTT ATT TTT TATA AAT TTT 
[ILII III IIIA 


void CDundesView: :OnItemsKey ( ) 


{ 


} 


void CDundesView: :OnUpdateItemsKey(CCmdUI* pCmdUI) 


{ 


} 


// TODO: Add your command handler code here 


ILLE IILI IAT EAA AS TTT TAT 
[I/III III IIIA 
// START CUSTOM CODE 

LAINIII ATIII I 
PULAA TILTTAA AAT ATA ITAI 


m_mode = Key; 


TAL TIA ANETA AA CAAT CTA CAAA 
CITEA TEAT EIAI EALE 
// END CUSTOM CODE 

[I/III TIITII IIIA 
ALELA IALIA ITEA LELE 


// TODO: Add your command update UI handler code here 


TAITEEN CUL AATEC LALELA 
CACAL ALLTAL 
// START CUSTOM CODE 

OLTEAN IA TULCEA ITEE LE 
TULTTTTTTTTTT TTT TTT TTT TTT ATT 


if (m_mode == Key) 

pCmdUI ->SetCheck (TRUE) ; 
else 

pCmdUI ->SetCheck (FALSE) ; 


TILAA TEA TTT TTT TTT TTT TTT 
[LIILIA 
// END CUSTOM CODE 

TIAIA TAAA AIIE LETALA 
[I/III IIIA 


void CDundesView: :OnItemsMonster () 


{ 


// TODO: Add your command handler code here 
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Listing 6.6 Continued 


[IIIIIIIIIII TTT TTT TTT TTA ATTA TL 
[TIETAS ATI IA TEELE AI 
// START CUSTOM CODE 

IPINITA AANT TAIAT ENINA IAAL EECA 
EITAN PAANI AA ATAA AAAI CEL 


m_mode = Monster; 


[IILI IIIA IIIN 

VISUSTI TTT TTT TTT TTT 

// END CUSTOM CODE 

FILITTTTTTTTT TTT TTT TAT TATA ATA 

FILTTTTTTTTTT TTT TATA TTT AAT AAT 
} 


void CDundesView: :OnUpdateItemsMonster (CCmdUI* pCmdUI) 


{ 
// TODO: Add your command update UI handler code here 


FTLITTTTTTTT TTT TTT TTT ATTA 
FIITITTTTTTT TTT TTT TTT TATA TATA TTL 
// START CUSTOM CODE 

[IIIIIIIII I IIIENA 
AIII TAEA EEA AEREE ECAA 


if (m_mode == Monster) 
pCmdUI ->SetCheck (TRUE) ; 
else 
pCmdUI ->SetCheck (FALSE) ; 


IIIA IAA AITA TATA TATA 

FILTLITTLTTTT TTT TATA ATA ATA ATT ATT 

// END CUSTOM CODE 

PAILAN IALA IN AAAI CAL ETITI 

TITTTTTTTTTTT TTT TTT TTT ATTA TATA TTL 
} 


void CDundesView: :OnItemsPotion() 


{ 
// TODO: Add your command handler code here 


[IIIIIIII IIIA 
VIIIC TICCI TTT AAT 
// START CUSTOM CODE 

LTLTTLTTTTTTT TTT ATT TATA AAA TTL 
FILTTTTTTTTT IAI ATTA AAT AAT TL 


m_mode = Potion; 


} 


void CDundesView: :OnUpdateItemsPotion(CCmdUI* pCmdUI) 


{ 


} 


/[IILIIIIIIII TTT TTT TTT TTT TTT 
[IILI IIIN 
// END CUSTOM CODE 

[LIII ITIITI 
[I/III III IIIT 


// TODO: Add your command update UI handler code here 


LILACS EACAN TAT TTT 
[III II IIIT 
// START CUSTOM CODE 

[ILILILILIL IIIA 
TAVLA LATET TEE ELIIT TTT 


if (m_mode == Potion) 

pCmdUI ->SetCheck (TRUE) ; 
else 

pCmdUI ->SetCheck (FALSE) ; 


[I/III I IIIA 
[ILII II IIIT 
// END CUSTOM CODE 

TITTTTTTTTTTTT TTT ANTAA ATT 
CIULEI LEANE ETEA AATE EL 


void CDundesView::OnItemsSword() 


{ 


} 


void CDundesView: :OnUpdateItemsSword(CCmdUI* pCmdUI) 


// TODO: Add your command handler code here 


[IIIT III IIIA 
UEILL IELAI TCE LA 
// START CUSTOM CODE 

[ILIITA ITIITI 
TTTTTTTTTTTTT TTT TTT TATA TTT TTT 


m_mode = Sword; 


[IIIT ITIITI 
[IIIIIIIIII ITIITI 
// END CUSTOM CODE 

[ILILILILIL 
[ILILILILIL 


// TODO: Add your command update UI handler code here 
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Listing 6.6 Continued 


[IILI II IIIN 
[ILILILILIL IIIA ATA ATL 
// START CUSTOM CODE 

PIIIILIINI ELET TTT TTT ATT TATA TAL 
[IILI I TTT TTT TTT ATA TL 


if (m_mode == Sword) 

pCmdUI ->SetCheck (TRUE) ; 
else 

pCmdUI ->SetCheck (FALSE) ; 


ILIENEA AITA TAT TAT 

TTLITTTTTTTTT ATL TAA ETEA 

// END CUSTOM CODE 

TIPLE IAI ELACA AL 

[IILI ILII IINIT 
} 


void CDundesView::0nItemsTreasure() 


{ 
// TODO: Add your command handler code here 


[IIIIIIIIIII TTT TTT TATA 
TITTTTTTTTTTTT TTT TTT TATA 
// START CUSTOM CODE 

TIITTTTTITTTT TTT TTT TTT TTA TATA TL 
TITTTTTTTTTT TTT TTT TATA TATA TL 


m_mode = Treasure; 


FTTTTITTTTTTTT TTT AAA INITA AAT ATA 

FTTTTTTTATTT TTT TTT AAT TATA TT 

// END CUSTOM CODE 

TITTTTTTTTTT TTT LATALI EEEE ATE 

[IIIILIIIII II IIIT 
} 


void CDundesView: :OnUpdateItemsTreasure(CCmdUI* pCmdUI) 


{ 
// TODO: Add your command update UI handler code here 


TIITA TT TTT AITA ECEAT TA 
CEFL ITIAI ALIAL TTT TATA TTL 
// START CUSTOM CODE 

PLIIIS NATAAN CEILALTI 
PEIA AACE ATAT 


if (m_mode == Treasure) 
pCmdUI ->SetCheck (TRUE) ; 
else 
pCmdUI ->SetCheck (FALSE) ; 


} 
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ILILILILIL 
FITLTTTTTTTTTT TTT TATA TATA TTT 
// END CUSTOM CODE 

[ILILILILIL 
TTLTTTTTTTTTT TTT TTT TATA TT 


void CDundesView: :OnItemsWall() 


{ 


} 


// TODO: Add your command handler code here 


[ILILILILIL 
LIIATI IAAI TAA TIAIA EAA TTT 
// START CUSTOM CODE 

PALIIT AANTALLEN IIT 
FULTTTTTTTTTT ATTA TATA 


m_mode = Wall; 


[IILI TTT TTT TTT TTT 
FTTTTTTTTTTTTTT TTT TTT TATA TTT 
// END CUSTOM CODE 

TITTLTTTTTTTT TTT TTT AATTEET A 
TILTTTTTTTTTTT TTT TTT TTT 


void CDundesView: :OnUpdateItemsWall(CCmdUI* pCmdUI) 


{ 


int 


// TODO: Add your command update UI handler code here 


PLAAS ISININ IIIENA EEEE AAEL 
FITTTTTTTTTT TTT TTT TTT TTT ATT 
// START CUSTOM CODE 

FASILA IIAL ASTEELLE 
PALA LALIALANI IISTI TTT ATTA TIELT 


if (m_mode == Wall) 

pCmdUI ->SetCheck (TRUE) ; 
else 

pCmdUI ->SetCheck (FALSE) ; 


TITITTITTITTT TTT TTTTTATATTTATT 
VISIITI ILALA AALT I 

// END CUSTOM CODE 

VELINTA TILAA LATE CIEE 
TILTITITTITTIT ASILIA EIT TEE 

CDundesView: :OnCreate(LPCREATESTRUCT lpCreateStruct) 


if (CView::OnCreate(lpCreateStruct) == -1) 
return -1; 


// TODO: Add your specialized creation code here 
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Listing 6.6 Continued 


[ILILILILIL TTT TTT TTT TATA ATT 
LTLLTTTTTTTT TTT ATTA TTT TATA 
// START CUSTOM CODE 

LITITTTTTTTTTT TTT TTT TATA ATA 
[ILILILILIL TTT TTT TTT ATT AAA ATTA ATT 


// Get a device context for the window. 
CClientDC clientDC(this) ; 


// Create a bitmap compatible with the window DC. 
m_pBitmap = new CBitmap; 
m_pBitmap->CreateCompatibleBitmap(&clientDC, 640, 480); 


// Create a memory DC compatible with the window DC. 
CDC memDC; 
memDC.CreateCompatibleDC(&clientDC) ; 


// Select the bitmap into the memory DC. 
memDC.SelectObject(m_pBitmap) ; 


// Clear the memory DC to white. 

CBrush* brush = new CBrush(RGB(255,255, 255) ) ; 
memDC.FillRect(CRect(®, ®, 639, 479), brush); 
delete brush; 


// Draw the dungeon grid on the memory bitmap. 
DrawGrid (&memDC) ; 


[I/III III IIIN ATA 
LELIA ELEA 
// END CUSTOM CODE 

LITTTTTTTLTT TTT TTT TTT ATTA TATA TTL 
[IILI II II IITTI 


return Q; 


} 


FUIALII IAL TA EER A AEEA 
FILLAN CENTI TTEA AATA 
// START CUSTOM CODE 

VIIALA LIAA ATIE A AELE A 
TISLATTU CA TEIA TIERA. 


void CDundesView: :DrawGrid(CDC* dc) 
{ 
// Draw the grid's vertical lines. 
for (int x=0; x<=COLSIZE; ++x) 
{ 
dc ->MoveTo(SQUARESIZE*x+OFFSET, OFFSET) ; 
dc ->LineTo (SQUARESIZE*x+OFFSET, 
SQUARESIZE*COLSIZE+OFFSET) ; 
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// Draw the grid's horizontal lines. 
for (int y=0; y<=ROWSIZE; ++y) 


{ 
dc ->MoveTo (OFFSET, SQUARESIZE*y+OFFSET) ; 
dc ->LineTo (SQUARESIZE*ROWSIZE+OFFSET , 
SQUARESIZE*y+OFFSET) ; 
} 


} 


[IIIT 
TITTTTTTTTTTTTT TTT TTT TATA TTA TL 
// END CUSTOM CODE 

[IILI TTT TTT TT TTT ATTA TAT TTT 
[IIIT III IIIT 


void CDundesView: :OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint) 


{ 
// TODO: Add your specialized code here and/or call the base class 


AIETAN AAI IEAA TATEA IAAL 
TITTTTTTTTTTTT TTT TATA TTT TTT TTT 
// START CUSTOM CODE 

IIIT TTT TTT TTT TTT TTT 
PIILA SIAII ATELA TELT ELI 


// Get a pointer to the document object. 
CDundesDoc* pDoc = (CDundesDoc*) GetDocument() ; 


// Create a DC for the window. 
CClientDC clientDC(this) ; 


// Create a memory DC that's 

// compatible with the window DC. 
CDC memDC; 
memDC.CreateCompatibleDC(&clientDC) ; 


// Select the dungeon-grid bitmap into the memory DC. 
memDC.SelectObject(m_pBitmap) ; 


// Iterate through each square in the dungeon grid. 
for (int i=; i<DUNGEONSIZE; ++i) 
{ 

// Get the currently indexed item. 

CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt (i) ; 


// Create and select a brush for the item. 
CBrush* brush = new CBrush(m_Colors[pItem->iType]); 
CBrush* oldBrush = memDC.SelectObject(brush) ; 
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Listing 6.6 Continued 


// Calculate the pixel position to draw the square. 
UINT row = i / ROWSIZE; 

UINT col = i - (row * ROWSIZE) ; 

UINT x = col * SQUARESIZE + OFFSET; 

UINT y = row * SQUARESIZE + OFFSET; 


// Draw the square on the bitmap. 
memDC.Rectangle(x, Yy, 
x+SQUARESIZE+1, y+SQUARESIZE+1) ; 


// Restore the DC and delete the brush. 
memDC.SelectObject(oldBrush) ; 
delete brush; 

} 


// Force the window to redraw. 
Invalidate() ; 


[IILI IIIA 

[IIIIIII ILIITA 

// END CUSTOM CODE 

[ILILILILIL II IIIT 

[IILI II IIIA 
} 


void CDundesView: :OnLButtonDown(UINT nFlags, CPoint point) 


{ 
// TODO: Add your message handler code here and/or call default 


IAITU TI TEIT AINN TANIA EEI AEAN EAT 
LILINO CAAA LLL 
// START CUSTOM CODE 

[IILI I IILI 
VECINII I ALA IIIENA AAT AAT 


// If the user clicked in the dungeon grid... 
if (ClickInsideGrid (point) ) 
{ 
// Calculate the square's column and row. 
UINT col = ((point.x - OFFSET) / SQUARESIZE) * 
SQUARESIZE + OFFSET; 
UINT row = ((point.y - OFFSET) / SQUARESIZE) * 
SQUARESIZE + OFFSET; 


// Calculate the square's number. 
UINT squareNum = (col / SQUARESIZE) + 
(row / SQUARESIZE) * ROWSIZE; 


// If the square is not unchangeable... 
if (!InStartingWalls(squareNum) ) 
HandleLeftClick(squareNum, col, row); 


FTTTTTTTTTTTTTT TTT TTT ATTA ATTA 
TITTTTTTTTTTTTT TAT TTT TTT AAT 
// END CUSTOM CODE 

(IILAN AN TT TTT TATA TT 
TITTTTTTTTTTT TTT TTT TT TTT ATTA 


CView: :OnLButtonDown(nFlags, point); 
} 


TUTTTTTTTTTTTTTT TTT TTT TTT TTT AAT 
[IIIT TTT TTT TT TTT ATTA 
// START CUSTOM CODE 

FITTTTTTTTTTTTT TTT TTT ATTA TTA TTT 
[ILILILILIL 


BOOL CDundesView::ClickInsideGrid(CPoint point) 
{ 


// Calculate width and height of grid in pixels. 


int gridSize = SQUARESIZE * ROWSIZE; 


// If the user clicked within the grid, return TRUE. 


if ((point.x < gridSize + OFFSET) && (point.x > OFFSET) && 


(point.y < gridSize + OFFSET) && (point.y > OFFSET) ) 


return TRUE; 


// Otherwise, return FALSE. 
return FALSE; 
} 


BOOL CDundesView: :InStartingWalls(int squareNum) 


{ 


// Determine whether the square is one of 
// the default wall squares. 


if ((squareNum > -1) && (squareNum < ROWSIZE) ) 


return TRUE; 

if ((squareNum > (COLSIZE-1)*ROWSIZE) && 
(squareNum < COLSIZE*ROWSIZE) ) 
return TRUE; 

if ((SquareNum % ROWSIZE 
(squareNum % ROWSIZE 
return TRUE; 

if ((squareNum == 93) |; (SquareNum == 94)) 
return TRUE; 

return FALSE; 


o) ii 
ROWSIZE-1)) 


} 
void CDundesView::HandleLeftClick(UINT squareNum, 


UINT col, UINT row) 

{ 
// Get a pointer to the document object. 
CDundesDoc* pDoc = GetDocument(); 


// Get the item at the selected square. 
CItem* pItem = 
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Listing 6.6 Continued . 


(CItem*) pDoc->m_Dungeon.GetAt (squareNum) ; 


// If the square already holds something... 
if (pItem->iType != Empty) 


{ 
// ...empty the square in memory... 
pItem->iType = Empty; 
// ...and redraw the square. 
CBrush* brush = new CBrush(RGB(255, 255, 255) ) ; 
DrawSquare(col, row, brush); 

} 


// Otherwise, place the appropriate 

// type of item in the square. 

else if (m_mode == Wall) 
PlaceWall(pItem, col, row); 

else 
PlaceItem(pItem, col, row, m_mode) ; 


// Tell the document object 
// that it's been modified. 
pDoc ->SetModifiedFlag() ; 


} 
void CDundesView: :PlaceWall(CItem* pItem, UINT x, UINT y) 


{ 
// Initialize the new wall item. 
pItem->iType = Wall; 
pItem->iNumber = 0; 
pItem->iValue = Q; 
// Create a brush for the wall from the color array. 
CBrush* brush = new CBrush(m_Colors[Wal11]) ; 
// Draw the new wall square on the screen. 
DrawSquare(x, y, brush) ; 
} 


void CDundesView: :PlaceItem(CItem* pItem, 
UINT x, UINT y, UINT itemType) 

{ 
// Display the Item dialog box. 
CItemDlg dlg; 
dlg.m_number = 0; 
dlg.m_value = Q; 
UINT result dlg.DoModal() ; 


// If the user exits the dialog box with the OK button... 
if (result == IDOK) 


// Get the requested item number. 
UINT itemNumber = dlg.m_number; 


} 
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// See whether the item already exists. 
WORD itemValue; 
BOOL found = 
FindItem(itemType, itemNumber, itemValue) ; 
result = IDNO; 


// No such item yet, so ask if user wants 
// to create a new item of the requested type. 
if (!found) 
result = MessageBox("Create new item?", 
"Item", MB_ICONQUESTION {| MB_YESNO) ; 


// If it's okay to create the item... 
if ((result == IDYES) į; (found) ) 
{ 
// Change the item object from empty 
// to the new item. 
pItem->iType = itemType; 
pItem->iNumber = itemNumber; 
if (found) 
piItem->iValue 
else 
pItem->iValue = dlg.m_value; 


itemValue; 


// Make sure the item number is within 
// proper bounds for the item type. 

if (NotValidItem(pItem) ) 

{ 

MessageBox("Item Number Not Valid", 
"Invalid Item", 
MB_ICONEXCLAMATION ; MB_OK); 

pItem->iType = Empty; 

itemType = Empty; 

pItem->iNumber = 0; 

pItem->iValue = 0; 

} 

// Draw the new item on the screen. 

CBrush* brush = new CBrush(m_Colors[itemType] ) ; 
DrawSquare(x, y, brush); 


} 
BOOL CDundesView: :NotValidItem(CItem* pItem) 


{ 


BOOL notValid = FALSE; 


// Check each item type for valid item numbers. 
switch(pItem->iType) 


{ 


case Door: 
case Key: 
if (pItem->iNumber > 5) 
notValid = TRUE; 
break; 
case Monster: 
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Listing 6.6 Continued 


} 


if (pItem->iNumber > 2) 
notValid = TRUE; 
break; 
case Sword: 
case Armor: 
if (pItem->iNumber > 0) 
notValid = TRUE; 
} 


return notValid; 


BOOL CDundesView: :FindItem(WORD itemType, 


{ 


WORD itemNum, WORD& itemValue) 


// Get a pointer to the document object. 
CDundesDoc* pDoc = GetDocument() ; 


BOOL found = FALSE; 
int i = 0; 


// Search through the item array until the item 
// is found or until the loop reaches the end 
// of the array. 
while ((!found) && (i<DUNGEONSIZE) ) 
{ 
// Get the currently indexed item. 
CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt (i) ; 


// Check whether the items match. 
if ((pItem->iType == itemType) && 
(pItem->iNumber == itemNum) ) 
{ 
itemValue = pItem->iValue; 
found = TRUE; 
} 


// Increment index variable. 
ttis 


} 


return found; 


} 
void CDundesView: :DrawSquare(UINT x, UINT y, CBrush* brush) 


{ 


// Create a DC for the window and a memory 
// DC compatible with the window DC. 
CClientDC clientDC(this) ; 

CDC memDC; 
memDC.CreateCompatibleDC(&clientDC) ; 


// Select the dungeon-grid bitmap into the memory DC. 
memDC.SelectObject(m_pBitmap) ; 
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// Select the brush into both DCs. 
CBrush* oldBrushi memDC.SelectObject (brush); 
CBrush* oldBrush2 clientDC.SelectObject (brush); 


// Draw the square in both DCs. 
memDC.Rectangle(x, y, 

x + SQUARESIZE + 1, y + SQUARESIZE + 1); 
clientDC.Rectangle(x, y, 

x + SQUARESIZE + 1, y + SQUARESIZE + 1); 


// Restore DCs and delete the brush. 
memDC.SelectObject(oldBrush1) ; 
clientDC.SelectObject(oldBrush2) ; 
delete brush; 

} 


[ILILILILIL IIIN 
FIUNN ETIA IEEE LLIA 
// END CUSTOM CODE 

[IILLIIIIII IIIA TTT TATA AAT 
[IIIIIIIIIII TTT TTT TT 


void CDundesView: :OnRButtonDown(UINT nFlags, CPoint point) 


{ 
// TODO: Add your message handler code here and/or call default 


[IIIIIIIIII TTT TTT TATA TAA AAT 
FTTLLTTTTT TTT TTT TATA TAA TAA ATT 
// START CUSTOM CODE 

[ILILILILIL TTT ATA ATA ATA TA 
[IILIIIIIII TTT TTT TATA TAA AAT TTL 


// If the user has clicked in the dungeon grid... 
if (ClickInsideGrid(point) ) 
{ 

// Get a pointer to the document. 

CDundesDoc* pDoc = GetDocument() ; 


// Calculate the clicked square's column, 
// row, and number. 

UINT col = (point.x - OFFSET) / SQUARESIZE; 
UINT row = (point.y - OFFSET) / SQUARESIZE; 
UINT itemNum = row * ROWSIZE + col; 


// Create a string object for displaying 
// the item's values. 
CString s("Type:\t"); 


// Get the selected item. 


CItem* pItem = 
(CItem*) pDoc->m_Dungeon.GetAt (itemNum) ; 


// Add the item type to the string. 
switch (pItem->iType) 
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Listing 6.6 Continued 


{ 
case Empty: s += "Empty"; break; 
case Wall: s += "Wall"; break; 
case Door: s += "Door"; break; 
case Treasure: s += "Treasure"; break; 
case Monster: s += "Monster"; break; 
case Key: s += "Key"; break; 
case Sword: s += "Sword"; break; 
case Armor: s += "Armor"; break; 
case Potion: s += "Potion"; break; 

} 


// Add the item number to the string. 
s += "\nNumber:\t"; 

char num[10]; 

itoa(pItem->iNumber, num, 10); 

s += num; 


// Add the item value to the string. 
s += "\nValue:\t"; 
itoa(pItem->iValue, num, 10); 

s += num; 


// Display the string containing 
// the item description. 
MessageBox(s, "Item", MB_OK); 


} 


UILLI TIIA ALTAI L TTT TT 
CAELIS T ITNT AAAA EEATT ITIITI 
// END CUSTOM CODE 

PLNIA LLATAI AAAA AITITE 
PIECA CL VAALEATA LAAI 


CView: :OnRButtonDown(nFlags, point); 
} 


void CDundesView: :OnPrint(CDC* pDC, CPrintInfo* pInfo) 


{ 
// TODO: Add your specialized code here and/or call the base class 


FITTTTTTTTTTT TTT EA AA 
LAIEMA TIATA TTT TTT TTT ATTA ATT 
// START CUSTOM CODE 

FIPTTTTTTTTTTT TTT TTT TTT TTA TTA 
LILLIE ERCAS AA TAE AALE E 


// Get the printer's horizontal and vertical resolution. 
UINT horDots pDC ->GetDeviceCaps(LOGPIXELSxX) ; 
UINT verDots pDC ->GetDeviceCaps(LOGPIXELSY) ; 


} 
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// Print the map. 
PrintMap(pDC, horDots, verDots) ; 


PISALA TATAL TALITI AAAI TATA 
[/IIIIIIIII ILIITA 
// END CUSTOM CODE 

//IILIIIIII IIIA 
/[IIIIIIIIIII IIIT 


//CView::OnPrint(pDC, pInfo); 


LITTTTTTTTT TTT TTT TT TTA TTT 
TITTTTTTTTTTTTT TTT TTA TAA ATTA TTT 
// START CUSTOM CODE 

IIIS IIAN AAT A EINTE TATA CE. 
FILTTTTTTTTTTT TTA TTT AAA AAA AAT 


void CDundesView: :PrintMap(CDC* pDC, 


{ 


UINT horDots, UINT verDots) 


// Get a pointer to the document. 
CDundesDoc* pDoc = GetDocument() ; 


// Calculate sizes for the current device context. 
UINT verOffset = verDots / 2; 

UINT horOffset = horDots / 2; 

UINT verSquareSize = verDots / 5; 

UINT horSquareSize horDots / 5; 


// Draw the grid's vertical lines. 
for (int i=0; i<=COLSIZE; ++i) 


{ 
UINT x1 = horSquareSize * i + horOffset; 
UINT y1 = verOffset; 
UINT x2 = x1; 
UINT y2 = verSquareSize * COLSIZE + verOffset; 
pDC->MoveTo(x1, y1); 
pDC->LineTo(x2, y2); 
} 


// Draw the grid's horizontal lines. 
for (i=; i<=ROWSIZE; ++i) 


{ 
UINT x1 = horOffset; 
UINT y1 = verSquareSize * i + verOffset; 
UINT x2 = horSquareSize * ROWSIZE + horOffset; 
UINT y2 = y1; 
pDC->MoveTo(x1, y1); 
pDC->LineTo(x2, y2); 
} 
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Listing 6.6 Continued 


// Draw the dungeon's objects onto the map. 
for (i=0; i<DUNGEONSIZE; ++i) 
{ 
// Get the currently indexed item. 
CItem* pItem = (CItem*) pDoc->m_Dungeon.GetAt (i) ; 


// Create and select a brush for the item. 
WORD item = pItem->iType; 

CBrush* brush = new CBrush(m_Colors[item] ); 
CBrush* oldBrush = pDC->SelectObject (brush) ; 


// Calculate the pixel coordinates 

// for drawing the square. 

UINT row = i / ROWSIZE; 

UINT col = i - (row * ROWSIZE); 

UINT x col * horSquareSize + horOffset; 
UINT y row * verSquareSize + verOffset; 


// Draw the square. 
pDC->Rectangle(x, y, xt+thorSquareSizet1, 
y+verSquareSize+1) ; 


// Restore the DC and delete the brush. 
pDC ->SelectObject(oldBrush) ; 
delete brush; 


} 


FITTTTTTTITTT TTT TTT TTT TTT TTT 
FILTTTTTTITTTT TTT TTT TTT TTT TT 
// END CUSTOM CODE 

FILTTTTITTTTTT TTT TTT TTT TTT TTT TTT 
MILIA EUC TTT TT TTT TTT 


Summary 


In this chapter, you learned to build the Dungeon Designer application, 
which not only enables you to create new dungeon layouts for Aztec Adven- 
ture, but also teaches you a great deal about using Visual C++ and AppWizard 
to quickly create useful programs. Most of the remaining chapters in this 
book apply what you’ve learned to the building of the Aztec Adventure appli- 
cation. Along the way, you'll discover how to use WinG programming in 
your games, as well as how some 3-D dungeon games work. 


Chapter 7 
Aztec Adventure and 
WinG 


In the previous chapter, you developed the Dungeon Designer application, 
which you can use to create dungeon layouts for Aztec Adventure. However, 
because Dungeon Designer doesn’t have sophisticated graphics needs, it 
doesn’t use WinG for its display. Aztec Adventure, on the other hand, must 
create a 3-D view in memory and then transfer that view to the main 
window’s client area. This is the perfect task for WinG. 


In this chapter, then, you begin to develop the Aztec Adventure program. 
First, you'll generate the basic AppWizard application, and then you'll install 
the code necessary to take advantage of WinG. When you’ve completed this 
chapter, Aztec Adventure will be able to generate an identity palette and 
display a bitmap image using that palette. 


Creating Aztec Adventure, Version 1 


Because Aztec Adventure is a fairly complicated program, you'll build the 
application a step at a time over the course of the next several chapters. In 
each version of the program, you’ll add another section of code, until you’ve 
finally completed the Aztec Adventure program. In this section, you create 
the basic AppWizard application on which the final Aztec Adventure program 
is based. 
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Fig. 7.1 

The options for 
the basic AZTEC 
application. 


1. Use AppWizard to create the basic files for the Aztec Adventure pro- 


gram, selecting the options listed in the following table. When you’re 
done, the New Project Information dialog box appears and should look 
like figure 7.1. 


Dialog Box Name Options to Select 


New Project Name the project AZTEC, and set the project path 
to C:\MSVC20. Leave other options set to their 
defaults. 

Step 1 Select Single Document. 

Step 2 of 6 Leave set to defaults. 

Step 3 of 6 Leave set to defaults. 

Step 4 of 6 Turn off all application features except Use 3D 
Controls. 

Step 5 of 6 Leave set to defaults. 

Step 6 of 6 Leave set to defaults. 


RS FY SPSL A SPR ED 


New Project Information 


Application type of aztec: 
Single Document Interface Application targeting: 
Win32 


Classes to be created: 
Application: CAztecApp in aztec.h and aztec.cpp 
Frame: CMainFrame in mainfim.h and mainfrm.cpp 
Document: CAztecDoc in aztecdoc.h and aztecdoc.cpp 
View; CAztecView in aztecvw,h and aztecvw.cpp 


Features: 
+ MSYC Compatible project file (aztec. mak) 
+ 3D Controls 


+ Uses shared DLL implementation (MFC30.DLL) 
+ Localizable text in U.S. English 


2. Double-click AZTEC.RC in the project window. The resource browser 


window appears, as shown in figure 7.2. 


3. Double-click the menu resource, and then double-click IDR_MAINFRAME to 


open the menu editor. Delete the Edit menu. The menu bar will then 
look like figure 7.3. 
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Fig. 7.2 
The resource 
browser window. 


Fig. 7.3 

Aztec Adventure’s 
menu bar in the 
menu editor. 


4. Change the command in the Help menu to &About Aztec Adventure..., 
as shown in figure 7.4. 


Fig. 7.4 
Editing Aztec 
Adventure’s 
Help menu. 
5. Delete all commands from the File menu except New and Exit. The 
result is shown in figure 7.5. 
» aztec-rc -IDR_MAINFRAME (Menu) 5) ee. Oo Fig. 7.5 
sag : SETH o Aztec Adventure’s 


File menu. 
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6. Close the menu editor and open the accelerator editor for the 
IDR_MAINFRAME accelerator table. Delete all accelerators except 
ID_FILE_NEW, as shown in figure 7.6. 


Fig. 7.6 
Aztec Adventure’s 
accelerator table. 


| A aztec.ic - IDR MAINFRAME (Accelerator) 


7. Close the accelerator editor and open the icon editor for the 
IDR_MAINFRAME icon. Modify the icon for the application. Or, if you like, 
just use Import, Cut, and Paste to copy the AZTEC.ICO file from this 
book’s CD-ROM (see fig. 7.7). You'll find the icon in the 
CHAPO7\AZTECI\RES directory. 


Fig. 7.7 ff aztec.rc - IDR_MAINFRAME (Icon) oid! 
Editing Aztec [a 


Adventure’s icon. 


8. Change the About dialog box to look like figure 7.8, adding and chang- 
ing static text, as well as changing the dialog box’s title. 


9. Close the dialog box editor and open the string table editor. Change 
the first segment of the IDR_MAINFRAME string to Aztec Adventure (see 
fig. 7.9). 
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IDD_ ABOUT BOX {Dialog} i E Fig. 7.8 
a Editing Aztec 
E | Adventure’s About 
| E | dialog box. 
Fig. 7.9 
: T = Sa TOE A, Changing Aztec 
‘APX_IDS_APP_TITLE A4 | aztec s as oe Adventure’s string 
AFX_IDS_IDLEMESSAGE at | table 
Create a new document\nNew . 
Open an existing document\nOpen 
Close the active document\nClose 
Save the active document\nSave 
Save the active document with a new name\nSave As 
_FILE_MAU_| Open this document 
ID_FILE_MRU_FILE2 Open this document 
ID_FILE_MRU_FILE3 Open this document 
ID FILE MRU FILE4 | 57619 _|_Open this document = 
Running Aztec Adventure, Version 1 
You’ve now created the basic Aztec Adventure application, as well as modi- 
fied its user interface. To compile the program, select the Project menu’s 
Rebuild All command. Visual C++ then compiles and links the application. 
When it’s finished, you can run Aztec Adventure by selecting the Project 
menu’s Execute command. When you do, you see the window shown in 
figure 7.10. 


Untitled - Aztec Adventure at f j Fig. 7.10 
i Aztec Adventure, 
Version 1. 
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At this point, Aztec Adventure is a long way from being a game. In fact, about 
the only thing you can do with the program is display its About dialog box 
(see fig. 7.11) by selecting the Help menu’s About Aztec Adventure command. 


Fig. 7.11 
Aztec Adventure’s 
About dialog box. 


About Aztec Adventure 


Aztec Adventure 1.0 
by Clayton Walnum 


Graphics by Maurice Molyneaux 


Copyright © 1995 
by Macmillan Computer Publishing 
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The first step in making the basic Aztec Adventure application into a game is 
to install the code necessary to take advantage of WinG. By using WinG, the 
program can assemble its 3-D view in an off-screen WinG buffer and then can 
call on WinG to transfer that buffer quickly to the screen. You’ll add the 
WinG code as you develop the next version of the application. 


The complete source code and executable file for this step in the creation of 
the Aztec Adventure application can be dion biel in the CHAPO7\AZTEC2 A 
tory of this book's CD-ROM. 


1. Select the Project menu’s Files command. The Project Files dialog box 
appears, as shown in figure 7.12. 


2. Set the List Files of Type list box to Library Files, and then use the 
Directories box to find the WING32.LIB file in the C:\WING\LIB direc- 
tory. Double-click WING32.L1B in the File Name box to add it to the 
project. When done, click the Close button. 


The WING32.LIB file tells the Visual C++ linker important information 
about the functions that you’ll be importing from the WinG DLL. 
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i i — ee Fig. 7.12 


Project Files 


The Project Files 
dialog box. 


3. Use ClassWizard to add the PreCreateWindow() function to 
MAINFRM.CPP, as shown in figure 7.13. 


; MFC ClassWizard Fig. 7.13 

shade var Adding 
PreCreateWindow() 
to MAINFRM.CPP. 


4. Add the following code to the PreCreateWindow() function, right after 
the // TODO: Add your specialized code here and/or call the base 
class comment: 

// Set the window's size. 


cs.cx = 550; 
cs.cy = 468; 


// Set the window's style. 
cs.style = WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU |WS_MINIMIZEBOX; 
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These lines set the width and height of the program’s main window. 
They also set the window’s style, creating an overlapped window with 
a caption bar, a system menu, and a Minimize box. The thick border, 
turned on by the WS_THICKFRAME style, has been left off so that the user 
can’t change the size of the window. The Maximize box, turned on by 
the WS_MAXIMIZEBOX style, has been left off for the same reason. 


5. Load the AZTECVW.H file and add the following lines to the top of the 
file, right before the CAztecView class’s declaration: 


#include "c:\wing\include\wing.h" 


const WINGDIBWIDTH = 240; 
const WINGDIBHEIGHT = 240; 


typedef struct BmInfo 


{ 
BITMAPINFOHEADER Header; 
RGBQUAD aColors[256]; 

} BmInfo; 


The first line includes WING.H in the file. WING.H is a header file that 
contains prototypes for the functions in the WinG library. Visual C++’s 
compiler needs these prototypes in order to compile any file that calls 
WinG functions. 


The second two lines define constants that represent the width and 
height of the WinG bitmap. BmInfo declares a BITMAPINFO structure type 
for the WinG bitmap. 


6. Also in the AZTECVW.H file, place the following lines in the CAztecView 
class’s Attributes section, right after the CAztecDoc* GetDocument() line: 
protected: 

HBITMAP m_hWinGDib; 
HBITMAP m_hOldBitmap; 
BmInfo m_WinGBmInfo; 
long m_orientation; 
void* m_pWinGDibBits; 
HDC m_hWinGDC; 
HPALETTE m_hPalette; 


The preceding lines declare the variables you need in order to incorpo- 


rate WinG into the program. These variables are declared as protected 
data members of the CAztecView class. 


7. Again in the AZTECVW.H file, place the following lines in the 
CAztecView class’s Implementation section, right after the protected 
keyword: 
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void SetUpWinGStuff () ; 

void DeleteWinGStuff () ; 

void CreateIdentityPalette() ; 
The preceding lines declare the functions you need in order to incorpo- 
rate WinG into the program. These functions are declared as protected 
member functions of the CAztecView class. 


8. Use ClassWizard to add the OnCreate() function to the CAztecView class, 
as shown in figure 7.14. 


f ` MFC ClassWizard 


WM_DESTROY. 


_WM_DROPFILES 5 


9. Add the following line to the OnCreate() function, right after the 
// TODO: Add your specialized creation code here comment: 


SetUpWinGStuf f () ; 


This line calls the function that sets up the WinG bitmap. 


10. Use ClassWizard to add the OnDestroy() function to the CAztecView 
class, as shown in figure 7.15. 


11. Add the following line to the OnDestroy() function, right after the 
// TODO: Add your message handler code here comment: 
if (m_hWinGDC) 
DeleteWinGStuff (); 
These lines delete the WinG DC and bitmap, by calling the 
DeleteWinGStuff() function just before the main window is 
destroyed. 


Fig. 7.14 
Adding OnCreate() 
to the CAztecView 
class. 
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Fig. 7.15 
Adding 
OnDestroy() to the 
CAztecView class. 


ON WM DESTROY 


12. Add the following lines to the OnDraw() function, right after the 
// TODO: add draw code for native data here comment: 


SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 
RealizePalette(pDC->m_hDC) ; 
WinGBitBlt(pDC->m_hDC, 51, 51, 

WINGDIBWIDTH, WINGDIBHEIGHT, m_hWinGDC, ©, @); 


These lines select and realize Aztec Adventure’s palette and then trans- 
fer the WinG bitmap to the window’s display. 


13. Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :SetUpWinGStuf f () 
{ 
// Get recommended format for the WinG bitmap. 
WinGRecommendDIBFormat 
((BITMAPINFO far *)&m_WinGBmInfo) ; 


// Save the suggested bitmap orientation. 
m_orientation = m_WinGBmInfo.Header.biHeight; 


// Set up the BITMAPINFO structure. 
m_WinGBmInfo.Header.biBitCount = 8; 
m_WinGBmInfo.Header.biCompression = BI_RGB; 
m_WinGBmInfo.Header.biWidth = WINGDIBWIDTH; 
m_WinGBmInfo.Header.biHeight = 
WINGDIBHEIGHT * m_orientation; 


// Create the identity palette. 
CreateIdentityPalette(); 


// Create the WinG device context. 
m_hWinGDC = WinGCreateDC(); 


} 
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// Create the WinG bitmap and select it into the WinG DC. 
m_hWinGDib = WinGCreateBitmap(m_hWinGDC, 

(BITMAPINFO far *)&m_WinGBmInfo, &m_pWinGDibBits) ; 
m_hOldBitmap = 

(HBITMAP) SelectObject(m_hWinGDC, m_hWinGDib) ; 


// Fill the WinG bitmap with blackness. 
PatBlt(m_hWinGDC, @, Q, 
WINGDIBWIDTH, WINGDIBHEIGHT, BLACKNESS) ; 


void CAztecView: :DeleteWinGStuff () 


{ 


} 


// Release the WinG bitmap by selecting the 
// old bitmap back into the WinG DC. 
HBITMAP hBitmap = 
(HBITMAP)SelectObject(m_hWinGDC, m_hOldBitmap) ; 


// Delete the WinG bitmap, DC, and palette. 
DeleteObject(hBitmap) ; 

DeleteDC(m_hWinGDC) ; 
DeleteObject(m_hPalette) ; 


void CAztecView: :CreateIdentityPalette() 


{ 


// Define a structure for the logical palette. 
struct 


WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[ 256] ; 

} logicalPalette = { 0x300, 256 }; 


// Get a device context for the screen. 
HDC hScreenDC = ::GetDC(Q); 


// Load the system palette into the 
// logical palette structure. 
GetSystemPaletteEntries 

(hScreenDC, @, 256, logicalPalette.aEntries) ; 


// Get rid of the screen DC. 
::ReleaseDC(@, hScreenDC) ; 


// Copy the system colors into the WinG bitmap's 
// color table and set the appropriate flags. 
for(int i = 0;i < 256;i++) 
{ 
m_WinGBmInfo.aColors[i].rgbRed = 
logicalPalette.aEntries[i] .peRed; 
m_WinGBmInfo.aColors[i].rgbGreen = 
logicalPalette.aEntries[i] .peGreen; 
m_WinGBmInfo.aColors[i].rgbBlue = 
logicalPalette.aEntries[i] .peBlue; 
m_WinGBmInfo.aColors[i].rgbReserved = Q; 
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Fig. 7.16 

Aztec Adventure 
with WinG 
incorporated into 
the program. 


logicalPalette.aEntries[i].peFlags = 0; 
} 


// Create the program's logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*)&logicalPalette) ; 
} 


These functions create the WinG DC and bitmap, as well as set up the 
identity palette. You’ll look more closely at these functions later in this 
chapter. 


This completes version 2 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 2 

When you run the new version of Aztec Adventure, you see the screen shown 
in figure 7.16. As you can see, the program has created a WinG bitmap and 
blitted it to the screen. Soon, that black rectangle will contain Aztec 
Adventure’s 3-D view window. For now, though, you'll have to be satisfied 
knowing that you’ve got WinG up and running. Of course, that’s not to say 
that you’re done with WinG. You still need to install the code that draws 
images on the WinG bitmap. Luckily, in Chapter 4, “Programming with 
WinG,” you developed the functions you need to handle this task. 
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Examining the SetUpWinGStuff () Function 

When the user starts Aztec Adventure, Windows sends a WM_CREATE message 
just before it displays the application’s main window. This message is 
handled by the cAztecView class’s OnCreate() function, whose task it is (in this 
particular application) to create the WinG DC and bitmap. To do this, 
OnCreate() calls the SetUpwinGstuff() function. 


The mechanics of setting up a WinG DC and bitmap should be familiar to 
you by now. First, SetUpWinGstuff() calls the WinGRecommendDIBFormat () 
function: 

WinGRecommendDIBFormat 

((BITMAPINFO far *)&m_WinGBmInfo) ; 

The preceding function call determines whether the application should use a 
bottom-up or top-down WinG bitmap. As you know, the suggested orienta- 
tion gets stored in the biHeight member of the BITMAPINFO structure’s header. 
The program saves the orientation by copying it into the m_orientation data 
member: 


m_orientation = m_WinGBmInfo.Header.biHeight; 


A value of 1 means that the application should use a bottom-up WinG 
bitmap, whereas -1 means a top-down WinG bitmap will work best. 


Next, the program fills in the BITMAPINFO structure with the values needed to 
create the appropriate bitmap: 
m_WinGBmInfo.Header.biBitCount = 8; 
m_WinGBmInfo.Header.biCompression = BI_RGB; 
m_WinGBmInfo.Header.biWidth = WINGDIBWIDTH; 


m_WinGBmInfo.Header.biHeight = 
WINGDIBHEIGHT * m_orientation; 


Because WinG currently handles only 8-bit bitmaps, the biBitCount member 
must be 8. Because a WinG bitmap is not compressed, biCompression is set to 
BI_RGB (defined as 0 in WINGDI.H). Finally, the program needs to set the size 
of the bitmap. The height gets stored in biHeight, and the width gets stored 
in biWidth. Notice that biHeight is multiplied by m_orientation, which, at this 
point, is either 1 or -1. Remember that a negative height creates a top-down 
bitmap, whereas a positive height creates a bottom-up bitmap. 


Next, the program must create the WinG bitmap’s palette, because if you try 
to create a WinG bitmap with an uninitialized palette, your program may act 
unpredictably. The program creates the bitmap’s palette by calling the 
CreateIdentityPalette() function: 


CreateIdentityPalette(); 
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The CreateIdentityPalette() function is defined later in the program. For 
now, just assume that this function fills in the WinG bitmap’s palette with 
valid values based on the current system palette. 


Once the BITMAPINFO structure is properly initialized, the program calls 
WinGCreateDC() to create a WinG device context: 


m_hWinGDC = WinGCreateDC() ; 


This function returns a handle to the WinG DC. The program stores the 
handle in the class data member m_hWineoc. 


Finally, the program can create the actual WinG bitmap, by calling the WinG 
API's WinGCreateBitmap() function: 


m_hWinGDib = WinGCreateBitmap(m_hWinGDC, 
(BITMAPINFO far *)&m_WinGBmInfo, &m_pWinGDibBits) ; 


This function returns a handle to a WinG bitmap that’s compatible with the 
WinG DC. The function’s arguments are the handle to the WinG DC, a 
pointer to the bitmap’s BITMAPINFO structure, and the address of a void 
pointer into which the function can store the address of the WinG bitmap’s 
image. Here, the data member m_pWinGDibBits will hold the bitmap image’s 
address. 


The WinG DC and bitmap are now ready to go. In order to display a black 
rectangle on the screen, rather than a lot of garbage, SetUpwinGStuff() calls 
PatB1t() to fill the WinG bitmap with black: 


PatBlt(m_hWinGDC, 0, 0, 
WINGDIBWIDTH, WINGDIBHEIGHT, BLACKNESS) ; 


Examining the DeleteWinGStuff() Function 

When the user shuts down Aztec Adventure, Windows sends a WM_DESTROY 
message to the application’s main window. This gives Aztec Adventure a 
chance to do any required, last-minute clean-up. In this case, the clean-up is 
deleting the WinG DC, bitmap, and palette. The function DeletewinGstuff () 
handles this clean-up. 


DeleteWinGStuff() first selects the old bitmap back into the WinG DC, which 
frees up, for deletion, the bitmap the program created: 


HBITMAP hBitmap = 
(HBITMAP)SelectObject(m_hWinGDC, m_hOldBitmap) ; 


SelectObject() returns a handle to the previously selected bitmap, which is 
the one you want to delete. DeletewinGstuff() then deletes the bitmap, DC, 
and palette by calling the appropriate function for each object: 
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DeleteObject(hBitmap) ; 
DeleteDC(m_hWinGDC) ; 
DeleteObject(m_hPalette) ; 


Examining the CreateldentityPalette() Function 

As you know, creating an identity palette is important for a WinG program, 
because it relieves Windows of having to map a logical palette to the device 
palette. Because version 2 of Aztec Adventure does not load and display any 
bitmaps, the program’s identity palette is based on the system palette, rather 
than a bitmap’s color table. The CreateIdentityPalette() function copies the 
system palette into the WinG bitmap’s color table. 


CreateIdentityPalette() first defines a structure for the application’s logical 
palette: 


struct 


{ 
WORD Version; 


WORD NumberOfEntries; 
PALETTEENTRY aEntries[256]; 
} logicalPalette = { 0x300, 256 }; 
Because the program will set the WinG bitmap’s palette to the system’s pal- 
ette, the function next calls the Windows function GetDC() to get a handle to 


the screen’s DC: 
HDC hScreenDC = ::GetDC(Q@); 


After getting a handle to the screen’s DC, a quick call to the Windows func- 
tion GetSystemPaletteEntries() copies the system palette into the 
PALETTEENTRY array: 

GetSystemPaletteEntries 

(hScreenDC, @, 256, logicalPalette.aEntries) ; 

If you remember from Chapter 4, “Programming with WinG,” this function’s 
parameters are a handle to a device context (in this case, the screen’s), the 
index of the first palette entry to receive, the number of palette entries to 
receive, and a pointer to the PALETTEENTRY array that will receive the colors. 


Once the program has the system colors stored in the PALETTEENTRY array, it 
no longer needs the screen DC, so it releases it by calling the Windows func- 
tion ReleaseDC(): 


::ReleaseDC(®@, hScreenDC) ; 


Now, the CreateIdentityPalette() function can copy the system colors into 
the palette array. It does this with a for loop: 
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for(int i = 0;i < 256;i++) 
{ 
m_WinGBmInfo.aColors[i].rgbRed = 


logicalPalette.aEntries[i] .peRed; 
m_WinGBmInfo.aColors[i].rgbGreen = 

logicalPalette.aEntries[i].peGreen; 
m_WinGBmInfo.aColors[i].rgbBlue = 

logicalPalette.aEntries[i] .peBlue; 
m_WinGBmInfo.aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = Q; 
} 


The final step is to create a logical palette from the array. The program does 
this by calling the Windows function CreatePalette(): 


m_hPalette = 
: CreatePalette((LOGPALETTE*)&logicalPalette) ; 


Examining the OnDraw() Function 

Creating a WinG DC and bitmap doesn’t do much good unless you display 
that bitmap on the screen. As you know, when it’s time to draw the view 
window’s display, the OnDraw() function gets called. 


At this point in Aztec Adventure, OnDraw() doesn’t do a heck of a lot. It sim- 
ply selects and realizes Aztec Adventure’s palette and then calls WinGBitB1t() 
to transfer the WinG bitmap from memory to the screen: 

SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 

RealizePalette(pDC->m_hDC) ; 

WinGBitBlt(pDC->m_hDC, 51, 51, 

WINGDIBWIDTH, WINGDIBHEIGHT, m_hWinGDC, ©, 0); 

Eventually, OnDraw() will do much more, displaying not only the WinG 
bitmap, but also all the other graphical elements that adorn Aztec 
Adventure’s main window. 
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At this point, you’ve got WinG incorporated into the program. You’ve cre- 
ated a WinG DC and selected a WinG bitmap into that DC. Finally, the 
program blits the WinG bitmap to the application’s main window. Unfortu- 
nately, this bitmap, being just a black rectangle, isn’t too exciting. So, the 
final step is to enable the application’s document class to load a bitmap to 
display on the screen. Along the way, you'll also need to modify the view 
class in order to create an identity palette from the newly loaded bitmap and 
to copy the source bitmap to the WinG bitmap in preparation for display. 
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The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAPO7\AZTEC3 directory of this 
book’s CD-ROM. = 


1. Copy the CDIB.CPP and CDIB.H files into the AZTEC project directory. 
(You’ll find CDIB.CPP and CDIB.H on this book’s CD-ROM, in the 
CHAP02\SHOWDIB directory.) 


2. Select the Project menu’s Files command. The Project Files dialog box 
appears, as shown in figure 7.17. In the File Name list box, double-click 
the CDIB.CPP file to add it to the project, and then click the Close but- 
ton to finalize your choice. 


Fig. 7.17 
The Project Files 
dialog box. 


3. Load AZTECDOC.H and place the following line at the top of the file, 
right before the CAztecDoc class declaration: 


#include "cdib.h" 


This lines makes the CDib class accessible in the CAztecDoc class. 


4. Also in AZTECDOC.H, add the following line to the CAztecDoc class’s 
Attributes section, right after the public keyword: 


CDib* m_pPartsADib; 


This line declares m_pPartsADib, a pointer to a CDib object, as a public 
data member of the CAztecDoc class. 
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5. 


Load the AZTECDOC.CPP file and add the following line to the class’s 
constructor, right after the // TODO: add one-time construction code 
here comment: 


m_pPartsADib = new CDib("LEVELO1A.BMP") ; 


This creates a CDib object from the bitmap found in the LEVELO1A.BMP 
file, which contains the image that you'll display in the application’s 
window. 


Also in AZTECDOC.CPP, place the following line in the CAztecDoc 
class’s destructor: 


delete m_pPartsADib; 
This line deletes the CDib object constructed by the class’s constructor. 


Load the AZTECVW.H file and add the following line to the CaztecView 
class’s Attributes section, right after the line HPALETTE m_hPalette that 
you placed there previously: 


CAztecDoc* pDoc; 


This line declares pDoc, a pointer to the application’s document class, as 
a protected data member of the cAztecView class. Because the program 
needs to access the document object often, it’s easier to store the 
pointer in a data member than it is to retrieve the pointer in every func- 
tion that needs it. 


Also in AZTECVW.H, add the following lines to the CAztecView class’s 
Implementation section, right after the other function declarations you 
placed there previously: 
void CreateIdentityPalette 
(BmInfo* winGBmInfo, CDib* pDib) ; 
void CopyDIBToWinG (BYTE* m_pWinGDibBits, 


UINT dstX, UINT dstY, CDib* pDib, 
UINT frmX, UINT frmY, UINT frmW, UINT frm) ; 


This code declares a new version of CreateIdentityPalette(), as well 
as CopyDIBToWinG(), aS protected member functions of the CAztecView 
class. The new version of CreateIdentityPalette() overloads the previ- 


ous version. You can call either version in the program, depending on 
the arguments you supply. 


Load the AZTECVW.CPP file and add the following lines to the 
CAztecView Class’s OnDraw() function, right before the call to 
WinGBitBlt() that you placed there previously: 


10. 


11. 


12. 
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// Copy the background image to the WinG bitmap. 
CopyDIBToWinG((BYTE*)m_pWinGDibBits, @, 0, 
pDoc->m_pPartsADib, @, 0, 240, 240); 


The preceding code copies the dungeon background scene from the cDib 
object containing the LEVELO1A.BMP image to the WinG bitmap. 


Also in AZTECVW.CPP, comment out the call to CreateIdentityPalette() 
in the SetUpWingstuff() function and add the following call to the new 
version of CreateIdentityPalette(): 


CreateIdentityPalette(&m_WinGBmInfo, pDoc->m_pPartsADib) ; 


This line calls the new version of the overloaded CreateIdentityPalette(). 


Again in AZTECVW.CPP, add the following line to the OnCreate() 
function, right before the call to SetUpwinGStuff (): 


pDoc = GetDocument(); 


This line initializes the pointer to the application’s document object. 


In AZTECVW.CPP, add the following functions to the end of the file: 


void CAztecView: :CreateIdentityPalette 
(BmInfo* winGBmInfo, CDib* pDib) 
{ 
struct 
{ 
WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[ 256]; 
} logicalPalette = {0x300, 256}; 


// Get the screen DC. 
HDC Screen = ::GetDC(Q); 


// Copy Windows' 20 standard system colors 
// into the new logical palette. 
GetSystemPaletteEntries 

(Screen, @, 10, logicalPalette.aEntries) ; 
GetSystemPaletteEntries 

(Screen, 246, 10, logicalPalette.aEntries + 246); 


// Get rid of the screen DC. 
::ReleaseDC(@,Screen) ; 


// Copy the standard 20 system colors into 
// the WinG bitmap's color table. 
for(int i = 0; i < 10; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed; 
winGBmInfo->aColors[i].rgbGreen = 
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logicalPalette.aEntries[i].peGreen; 
winGBmInfo->aColors[i].rgbBlue = 

logicalPalette.aEntries[i].peBlue; 
winGBmInfo->aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = 0; 


winGBmInfo->aColors[i + 246].rgbRed = 
logicalPalette.aEntries[i + 246].peRed; 
winGBmInfo->aColors[i + 246].rgbGreen = 
logicalPalette.aEntries[i + 246].peGreen; 
winGBmInfo->aColors[i + 246].rgbBlue = 
logicalPalette.aEntries[i + 246] .peBlue; 
winGBmInfo->aColors[i + 246].rgbReserved = 0; 


logicalPalette.aEntries[i + 246].peFlags = 0; 
} 


// Get a pointer to the source bitmap's color table. 
LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr() ; 


// Copy the source bitmap's color table into both 
// the WinG bitmap color table and 
// into the new logical palette. 
for(i = 10; i < 246; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed = 
pColorTable[i] .rgbRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen = 
pColorTable[i].rgbGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i].rgbBlue; 
winGBmInfo->aColors[i].rgbReserved 


0; 


logicalPalette.aEntries[i].peFlags 
PC_NOCOLLAPSE; 


} 


// Create the logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*)&logicalPalette); 
} 


void CAztecView: :CopyDIBTOWinG 
(BYTE* m_pWinGDibBits, UINT dstX, UINT dstY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frmH) 


// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight() ; 
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// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr(); 


// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=0; col<frmW; ++col) 


{ 
DWORD newSrcyY = srcHeight - frmH - frmY + row; 


if (m_orientation == -1) 

newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 

newSrcY * srcWidth + col + frmx; 
DWORD newDstY = 

WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 

newDstY = row + dstY; 
DWORD dstIndex = 

newDstY * WINGDIBWIDTH + col + dstX; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex]; 


} 


You should recognize these functions from Chapter 4, “Programming 
with WinG.” The new version of CreateIdentityPalette() (which over- 
loads the previous version) creates an identity palette from the color 
table of a CDib object, rather than from the system palette as the other 
version does. CopyDIBToWinG() copies an image from a source bitmap to 
the WinG bitmap. 


This completes version 3 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 


application. 


Running Aztec Adventure, Version 3 

Before you run this version of Aztec Adventure, make sure you copy the 
LEVELO1A.BMP file from the CHAPO7\AZTEC3 directory on this book’s CD- 
ROM to the directory that contains the new Aztec Adventure executable you 
just created. Then, when you run the program, you should see the window 
shown in figure 7.18. 


As you can see, the program now displays an actual image on the screen. This 
image is the background used as the starting point for Aztec Adventure’s first- 
floor 3-D view. You can see the dungeon floor, a cloud of mist, and blue sky 
above the mist. In the next chapter, you’ll add program code to draw walls 
and doors on top of this background in order to create a 3-D view of the dun- 
geon. For now, though, take a look at the new code you added to this version 
of Aztec Adventure. 
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Fig. 7.18 | Aztec Adventure 
Version 3 of Aztec Help 
Adventure. 


Examining the CAztecDoc Class’s Constructor 

In an MEC program, you use the document class to hold data that must be 
loaded and saved to and from the hard disk, whereas the view class is charged 
with displaying and editing the data held in the document class. In Aztec 
Adventure, you could debate over exactly what data belongs in the document 
class. For example, although Aztec Adventure must load many bitmaps in 
order to create its display, the bitmaps are not really part of a document in 
the same way that a text document or spreadsheet is. 


In fact, you could say that the application’s document is made up of the vari- 
ables that you save in order to store a player’s position in the game. Still, 
when a player changes his position in the dungeon, he changes not only the 
values stored in these variables, but also changes the display on the screen. 
So, in a'way, the graphics are part of the document. 


The bottom line: Because Aztec Adventure doesn’t load and save game posi- 
tions, I chose to use the document class to handle the bitmaps. A good place 
to load bitmaps is in the class’s constructor. 


In the constructor, the program creates a CDib object from the 
LEVELO1A.BMP file, which contains some of the graphics Aztec Adventure 
uses to create its display: 


m_pPartsADib = new CDib("LEVELQ1A.BMP") ; 
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The astute among you may wonder why the bitmap isn’t loaded in the 
CAztecDoc Class’s Serialize() function, where an AppWizard-generated 
application’s data is usually loaded and saved. One reason is that a CDib ob- 
ject has its own file-loading code, one that doesn’t deal with CArchive objects 
as the Serialize() function does. But there’s an even more logical reason. 


Remember that the Serialize() function gets called when the user selects the 
File menu’s Open and Save commands. If you were playing a game and chose 
the Open command, what would you expect the program to load? A game- 
save file, right? You surely wouldn’t expect the program to load graphics for 
the display. The game should perform that task automatically at start-up 
time. (Currently, Aztec Adventure doesn’t have a save-game mechanism, but 
you might want to install one. To do that, you’d use Serialize() to load and 
save the variables that define the player’s position in the game.) 


In upcoming versions of Aztec Adventure, you’ll load many other bitmaps in 
the CAztecDoc class’s constructor. All those bitmaps, as well as the one loaded 
in this version of the program, are deleted in the class’s destructor. 


Examining the CreateldentityPalette() Function 

In version 2 of Aztec Adventure, the application created its identity palette 
from the current system palette. Although this method works fine for applica- 
tions that use only the system colors, it leaves you with less than desirable 
results when you need to display a 256-color bitmap. 


To display such an image properly with WinG, you must create an identity 
palette from both the system colors and the source bitmap’s color table. The 
bottom and top 10 colors of the palette (20 colors in all) are set to the 
system’s colors, whereas the rest of the palette gets its values from the source 
bitmap’s color table. The second version of the CreateIdentityPalette() 
function creates an identity palette in this way. 


Aztec Adventure uses the same CreateIdentityPalette() function you devel- 
oped in Chapter 4, “Programming with WinG.” 


Examining the CopyDIBToWinG() Function 

As you learned in Chapter 4, “Programming with WinG,” one of the big ad- 
vantages of WinG is your ability to directly access and modify a bitmap’s 
image in memory. In that chapter, you developed a function called 
CopyDIBToWinG(), which copies all or part of a source bitmap’s image to any 
location within a WinG bitmap. Aztec Adventure also uses CopyDIBToWinG(). 
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In Chapter 4, you learned how this function worked. If you need an in-depth 
refresher, please refer back to Chapter 4. 


Examining the OnDraw() Function 

In the previous version of Aztec Adventure, the program displayed only a 
black rectangle. Now, however, before transferring the WinG bitmap to the 
screen, the OnDraw() function must copy the source image to the WinG 
bitmap. You modified OnDraw() to handle this task. 


As usual, OnDraw() must first select and realize the application’s palette, which 
is now the identity palette created from both the system colors and the 
source bitmap’s color table: 


SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 
RealizePalette(pDC->m_hDC) ; 


Next, the program copies the dungeon-background image from the source 
bitmap to the WinG bitmap: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 0, Q, 
pDoc->m_pPartsADib, 0, ©, 240, 240); 
Finally, a call to WinGBitB1t() copies the WinG bitmap to the application’s 
window: 


WinGBitBlt(pDC->m_hDC, 51, 51, 
WINGDIBWIDTH, WINGDIBHEIGHT, m_hWinGDC, @, 0); 


Summary 


Because of its graphical intensity, Aztec Adventure is a good candidate for 
using WinG. To take advantage of WinG in Aztec Adventure, the program 
must create a WinG bitmap and DC, as well as create an identity palette from 
the system’s 20 static colors and the middle 236 colors of the source bitmap’s 
color table. Then, to display graphics, the program builds an image by copy- 
ing parts of the source bitmaps to the WinG bitmap and then calls 
WinGBitB1t() to display the image on the screen. 


Now that you have WinG installed into Aztec Adventure, you can start learn- 
ing how to create pseudo-3-D views in dungeon games. Although there are 
lots of complicated ways to build 3-D images, you may be surprised at how 
simple Aztec Adventure’s method is. 


Chapter 8 
The Pseudo 3-D 
Viewpoint 


You’ve done a lot of studying so far, but, at last, you’re going to get the an- 
swer to that question that’s been burning in your mind: How the heck can 
Aztec Adventure create a 3-D view of virtually any location within the dun- 
geon grid? No matter how you rearrange a dungeon floor with Dungeon 
Designer, no matter where you move within the dungeon, Aztec Adventure 
creates a 3-D, first-person viewpoint that represents your location. Seems 
almost impossible, doesn’t it? 


But, just like a magic trick revealed by a magician, the technique used to 
create the 3-D image is painfully simple. Believe it or not, the method re- 
quires virtually no math. Anyone who has tried to figure out the numbers 
behind 3-D object rendering will undoubtedly enjoy this little bonus. Forget 
matrix multiplications, sines, and cosines. Although such calculations play 
an important part in smoothly scrolling games such as flight simulators, you 
don’t need them here. 


Standing on the Grid 


As you know, each dungeon floor in Aztec Adventure is a 32 x 32 grid, as 
shown in figure 8.1. Suppose, for a minute, that you could shrink yourself 
down so tiny that you could actually stand on a single square in this grid. 
Now, add the following rules to this tiny universe in which you suddenly 
find yourself: 


@ You can face only four directions: north, east, south, and west. 


E You can see no further than three squares in front of you. 
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E You have to move by jumping from the center of one grid square to the 
center of the next. 


@ You must wear a special helmet that has a square, glass faceplate. 


Assuming that the dungeon grid on which you're standing is devoid of any 
objects such as walls and doors, and assuming the preceding rules, you’d 
have a view of the grid like that shown in figure 8.2. 


Fig. 8.1 

An empty 
dungeon-floor 
grid. 


Fig. 8.2 
The dungeon-grid 


3-D view. Fades to darkness 


The third visible 


The second visible row of squares 


row of squares 

The first visible 

row of squares 

The visible portion of the 


The visible portion 
square to your immediate left 


of the square to 


your immediate 
The visible portion of the right 


square on which you're standing 
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At the very bottom of the viewplate is a small part of the grid square on 
which you're standing. To the immediate left and right are the portions of 
the squares left and right of you. In front of you are the three rows of squares 
you can see, after which the dungeon fades into darkness. If you ignore the 
very tiny bits of the far left and right squares that peek into the view in the 
second-to-last row, you end up with a view that’s constrained like that shown 
in figure 8.3. 


Fig. 8.3 

The squares to 
which your view 
is constrained. 


The black dot in figure 8.3 marks where you’re standing, and the arrow shows 
the direction in which you're looking. As figure 8.3 shows, under the rules 
you've set up, you can never see the contents of more than 14 squares. More- 
over, because you can face only north, east, south, or west, you always end 
up with the view shown in figure 8.3, no matter which way you turn in the 
grid (see fig. 8.4). 


Fig. 8.4 

The view is 
constrained 
exactly the same 
from all four 
viewing angles. 


| 
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South-facing View Westfacing View 


Because of this simplified view, creating a pseudo 3-D image of any configura- 
tion of dungeon walls requires only 13 wall images. (You can never have a 
wall in the same square on which you're standing, so you don’t need a wall 
image for the 14th square.) Figure 8.5 shows what these basic images look 
like. (In the actual game, the images are much more detailed.) 
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Fig. 8.5 

The 13 images 
needed to build 
any view ofa 


dungeon’s walls. 


The five images in the top row of figure 8.5 are the walls for the farthest row 
from your viewing point. The images in the second row are the next closest 
walls. The smaller images in the bottom row are the walls for the row of 
squares directly in front of you, and the remaining two images (the tall, 
skinny ones) are for the visible portions of the walls to your immediate left 
and right. 


Notice how the walls are drawn to show the correct perspective from the 
viewing point. That is, walls that are to the left or right from your straight-on 
viewing angle show two sides, whereas walls that you would view straight-on 
show only one side—the front. Notice also that the wall images are rectangles 
that contain bits of the dungeon floor and ceiling, and that the images that 
will appear farther from the viewpoint are darker. (Again, the floor and ceil- 
ing in the actual game are much more detailed. The images in figure 8.5 are 
simpler so that their construction and placement are more clear.) 


How do these images fit together to form a complete 3-D view? Suppose that 
you're still standing on the dungeon grid, but the grid is now no longer 
empty. Now there are two walls to the far right and left of the last row you 
can see, as shown in figure 8.6, where the two black squares represent the 
walls. With walls in that position, you’d use the images shown in figure 8.7 
to construct the view. 
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In figure 8.7, notice how the wall pieces fit perfectly inside the area framed by 
their squares. Also, because these walls are to your left and right, you’re look- 
ing at them from a slight angle. This means that you can see not only the 
front face of the walls, but also one of the sides. The wall images were drawn 
to reflect this important point of perspective. 


Now, add a wall next to the existing wall on the left, as shown in figure 8.8. 


Fig. 8.6 

Two distant walls 
on the dungeon 
grid. 


Fig. 8.7 

The 3-D view 
formed from the 
wall configuration 
in figure 8.6. 


Fig. 8.8 
Three walls on the 
dungeon grid. 


Fig. 8.9 

The 3-D view 
formed from the 
wall configuration 
in figure 8.8. 
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Fig. 8.10 
Four walls on the 
dungeon grid. 


Fig. 8.11 
The 3-D view 
formed from the 


wall configuration 


in figure 8.10. 


The image for the new wall fits in its grid square such that it covers the side 
face of the wall to its left. Also, because you’re viewing this new wall from less 
of an angle, less of its side wall shows than did the side wall of the original 
image. As you can see, when building the 3-D view with the wall images, you 
must place the images in the grid starting from the outside pieces and work- 
ing toward the center. 


Now, place another wall in the farthest row of the grid, as shown in figure 
8.10. This arrangement yields the view shown in figure 8.11. 


Because you're viewing the wall added in figure 8.11 straight on, only its face 
shows. Also, as usual, the new wall fits in its square such that it covers the 
part of the wall to its left that should no longer be visible. 


Just as you must build the image of any particular row by working toward the 
center, so you must place the images from back to front. For example, look at 
figure 8.12, which shows a wall added to the left of the first visible row. The 
equivalent 3-D view built from the wall images is shown in figure 8.13. 


In figure 8.13, you can see why you must construct the 3-D view from back to 
front. If you were to do it the other way around, walls in the rear would cover 
walls closer to you, which just doesn’t make sense. 


Try one more configuration, just to be sure you’ve got the hang of it. Add 
another wall as shown in figure 8.14. The 3-D view formed from this configu- 
ration is shown in figure 8.15. Although the new wall hides the far-right wall 
in the last row, you can still see the opening that leads deeper into the 
dungeon. 
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Fig. 8.12 
Five walls on the 
dungeon grid. 


Fig. 8.13 

The 3-D view 
formed from the 
wall configuration 
in figure 8.12. 


Fig. 8.14 
Six walls on the 
dungeon grid. 


Fig. 8.15 

The 3-D view 
formed from the 
wall configuration 
in figure 8.14. 
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Now that you understand how the 13 wall images work together to create a 
3-D view of the dungeon, it’s time to write the part of the program that ana- 
lyzes the dungeon grid and assembles a 3-D view for your current location in 
the grid. This part of the program works by locating the 14 squares that you 
should be able to see from your position in the dungeon, and then blitting 
the appropriate wall images to those squares that contain walls. 
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The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found i in the salsa AZ T so directory of this 


1. Load the AZTECDOC.H file and add the following lines to the 
CAztecDoc Class’s Attributes section, right after the CDib* m_pPartsADib 
line you placed there previously: 

CDib* m_pPartsBDib; 
UINT m_playerxX, m_playeryY; 
UINT m_faceDir; 


UINT m_floorNum; 
CPtrArray m_Dungeon; 


protected: 
CString* m_pLevelFileName; 
BOOL m_gameOver; 


The preceding lines declare data members for the CAztecDoc class. 
The first five data members are declared as public, and so they can 
be accessed by the CAztecView class. The protected data members 
m_pLevelFileName and m_gameOver are accessible only from within the 
CAztecDoc class. 


2. Also in AZTECDOC.H, add the following line to the CAztecDoc class’s 
Implementation section, right after the protected keyword: 


void LoadLevel() ; 


This line declares LoadLevel() as a member function of the CAztecDoc 
class. 


3. Load the AZTECDOC.CPP file and add the following lines to the 
CAztecDoc class’s constructor, right after the m_pPartsADib = new 
CDib("LEVEL@1A.BMP") line you placed there previously: 

m_pPartsBDib = new CDib("LEVEL01B.BMP") ; 


m_pLevelFileName = new CString("LEVEL@1.DUN"); 
m_gameOver = FALSE; 


The first line constructs a CDib object from the bitmap found in the 
LEVELO1B.BMP file, which contains the alternate set of images for the 
dungeon’s walls and doors. To give the illusion of motion as you move 
from one square in the dungeon to the next, the program switches 
between the two sets of images each time it constructs the 3-D view. 
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The second line constructs a CString object to hold the current file 
name for the floor. The third line initializes the game-over flag. 


4. Add the following lines to the CAztecDoc class’s destructor, right after 
the delete m_pPartsADib line you placed there previously: 


delete m_pPartsBDib; 
delete m_pLevelFileName; 


These lines delete the second CDib object and the CString object when 
the program terminates. 


5. Also in AZTECDOC.CPP, add the following lines to the OnNewDocument () 
function, right after the // (SDI documents will reuse this document) 
comment: 


// Initialize game variables for a new game. 
m_floorNum = 1; 

m_playerx ti 

m_playerY 15 

m_faceDir East; 


nou 


// Load data for the current floor. 
LoadLevel() ; 


// Notify the view of a change in the document. 
UpdateAllViews (NULL) ; 


The first four lines of code initialize the variables that position the 
player in the dungeon. The player starts on floor 1, facing east, in the 
square located at column 1, row 1. The fifth line of code loads the item 
data, as defined by Dungeon Designer, for the current dungeon floor. 
Finally, the call to UpdateAllViews() notifies the CAztecView object that 
the document’s data has changed. 


6. Add the following function to the end of the AZTECDOC.CPP file: 


void CAztecDoc::LoadLevel() 


{ 
CFile file; 
char far* pFileName; 


// Get a pointer to the current file name. 
pFileName = m_pLevelFileName ->GetBuffer (12) ; 


// Open the dungeon data file for the current floor. 
BOOL opened = file.Open(pFileName, CFile::modeRead) ; 


// If the file opened okay... 
if (opened) 


// Construct an archive object from the file. 
CArchive ar(&file, CArchive::load) ; 
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// Read all dungeon items and add them 
// to the item array. 
for (int i=@; i<DUNGEONSIZE; ++i) 


{ 
CItem* pItem = new CItem; 
ar >> pItem->iType; 
ar >> pItem->iNumber; 
ar >> pItem->iValue; 
m_Dungeon.Add(pItem) ; 

} 


// Close the archive object and the file. 
ar.Close(); 
file.Close(); 


} 


// If there's an error loading the data, 
// end the game. 
else 
m_gameOver = TRUE; 
} 


This function loads the data file for the current floor of the dungeon. 


The data file is one that you created with Dungeon Designer. You'll 
study this function in detail later in this chapter. 


Use ClassWizard to add the DeleteContents() function to the CAztecDoc 
class. Add the following lines to that function, right after the // TODO: 
Add your specialized code here and/or call the base class comment: 


// Get the number of elements in the m_Dungeon array. 
UINT size = m_Dungeon.GetSize(); 


// If the array isn't empty, delete its contents. 
if (size > ®) 


{ 
for (int i=; i<DUNGEONSIZE; ++i) 
delete m_Dungeon.GetAt (i); 
m_Dungeon.RemoveA11() ; 
} 


The DeleteContents() function is called right before a document is de- 
stroyed. Also, in a single-document interface (SDI) application such as 
Aztec Adventure, DeleteContents() is called right before a new docu- 
ment is created, giving the application a chance to clean up any old 
data associated with the current document. In the preceding case, 
DeleteContents() first checks to make sure the m_Dungeon array is not 
empty. (Remember, the first time DeleteContents() is called is right 
before creating the application’s first document, so m_Dungeon won’t 
contain old pointers.) If m_Dungeon contains pointers, the for loop de- 
letes the data associated with the pointers, and the call to RemoveAll () 
clears the array. 


8. 


10. 
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Load AZTEC.H and add the following lines to the top of the file, just 
after the #include "resource.h" line: 


enum { North, East, South, West }; 


const DUNGEONSIZE = 1024; 
const ROWSIZE = 32; 
const COLSIZE 32; 


enum {Empty, Wall, Door, Key, Monster, 
Treasure, Sword, Armor, Potion}; 


struct CItem 


{ 
WORD iType; 
WORD iNumber; 
WORD iValue; 
}; 


The first line declares an enumeration for the four possible directions 
in which you can face in the dungeon. The other data declared here 
should be familiar to you from the Dungeon Designer program. This 
data includes constants for the dungeon’s size, an enumeration for the 
types of items that can be found in the dungeon, and a structure to 
hold information about each item. 


Load AZTECVW.H and add the following lines to the CAztecView class’s 
protected Attributes section, after the other data members you declared 
there previously: 

CDib* m_pPartsDib; 


UINT m_objects[13]; 
BOOL m_gameOver; 


These lines declare m_pPartsDib (a CDib pointer), m_objects[] (an array 
of unsigned integers), and m_gameOver (a Boolean flag) as data members 
of the CAztecView class. 


Also in AZTECVW.H, add the following lines to the CAztecView class’s 
protected Implementation section, after the other function declarations 
you placed there previously: 


void CalcView(BOOL toggleBMP) ; 
void DrawView(); 

void CalcNorthView(int* blocks) ; 
void CalcEastView(int* blocks) ; 
void CalcSouthView(int* blocks) ; 
void CalcWestView(int* blocks); 
void InitNewGame() ; 

void ShowScene(); 
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Fig. 8.16 
Adding the 
OnUpdate() 
function to the 


CAztecView class. 


These lines declare the member functions that build the 3-D view for 
the player’s current position in the dungeon, as well as declare a func- 
tion for initializing a new game. 


11. Use ClassWizard to add the Onupdate() function to the CAztecView class, 
as shown in figure 8.16. 


wrens ae 


_WindowProc 


ON_WM_CREATE 
ON_WM_DESTROY 


OnUpdate() gets called whenever the document class calls its 
UpdateAllViews() function. 


12. Add the following lines to OnUpdate(), right after the // TODO: Add your 
specialized code here and/or call the base class comment: 


// Initialize the view's game variables. 
InitNewGame () ; 


// Reinitialize the WinG DC, bitmap, 
// and identity palette. 
DeleteWinGStuff (); 

SetUpWinGStuff (); 


// Set the pointer to the bitmap containing 
// the wall and door objects. 
m_pPartsDib = pDoc->m_pPartsADib; 


// Set up the identity palette. 

CClientDC clientDC(this) ; 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Build the 3-D view and copy it to the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 
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// Force the main window to redraw. 
Invalidate(FALSE) ; 


You'll look at the OnUpdate() function later in this chapter. 


13. In AZTECVW.CPP, comment out the call to CopyDIBToWinG() that you 
previously placed in the OnDraw() function. 


In this version of Aztec Adventure, the DrawView() function builds the 
3-D image in the WinG bitmap. 


14. Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :CalcView(BOOL toggleBMP) 
{ 
// Return immediately if the game is over. 
if (m_gameOver) 
return; 


int blockNums[13]; 


// Get the numbers of the visible squares. 
switch (pDoc->m_faceDir) 


{ 
case North: CalcNorthView(blockNums); break; 
case West: CalcWestView(blockNums); break; 
case South: CalcSouthView(blockNums); break; 
case East: CalcEastView(blockNums); break; 

} 


// Store the object types for the 13 visible 
// squares in the m_objects[] array. 
for (int i=; i<13; ++i) 


// If the square is off the grid, set it to empty. 
if ((blockNums[i] < @) ii 
(blockNums[i] > DUNGEONSIZE -1) ) 
m_objects[i] = Empty; 
else 
{ 
// Get a pointer to the item for the square. 
CItem* item = 
(CItem*) pDoc->m_Dungeon.GetAt (blockNums[i]) ; 


// Store the item's type in the object array. 
m_objects[i] = item->iType; 


} 


// If requested, switch between dungeon images. 
if (toggleBMP) 


if (m_pPartsDib == pDoc->m_pPartsADib) 
m_pPartsDib = pDoc->m_pPartsBDib; 
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} 


else 


m_pPartsDib = pDoc->m_pPartsADib; 


void CAztecView: :CalcNorthView(int* blocks) 


{ 


} 


// Calculate the visible blocks 


// player 
blocks[Q@] 
blocks[1] 
blocks[2] 
blocks[3] 
blocks[4] 
blocks[5] 
blocks[6] 
blocks[7] 
blocks[8] 


i 


s facing north. 
(pDoc ->m_playeryY-3) 


= (pDoc->m_playeryY-3) 


blocks[9] = 
blocks[10] = (pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx; 
= pDoc->m_playerY * ROWSIZE + pDoc->m_playerX - 1; 
= pDoc->m_playerY * ROWSIZE + pDoc->m_playerX + 1; 


blocks[11] 
blocks[12] 


(pDoc ->m_playeryY-3) 
(pDoc ->m_playerY-3) 
(pDoc ->m_playeryY-3) 
(pDoc ->m_playeryY-2) 
(pDoc->m_playery -2) 
(pDoc->m_playery -2) 
(pDoc->m_playery -1) 
(pDoc->m_playery -1) 


when the 


* 
* 
* 
* 
* 
* 
* 
* 
* 
* 


ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 


void CAztecView: :CalcEastView(int* blocks) 


{ 


} 


void CAztecView 


{ 


// Calculate the visible blocks when the 


// player 
blocks[@] 
blocks[1] 
blocks[2] 
blocks[3] 
blocks[4] 
blocks[5] 
blocks[6] 
blocks[7] 
blocks[8] 
blocks[9] 
blocks[10] 
blocks[11] 
blocks[12] 


i 


s facing east. 
(pDoc->m_playery -2) 
(pDoc ->m_playerY+2) 
(pDoc->m_playery -1) 
(pDoc ->m_playerY+1) 
(pDoc->m_playeryY) * 


* 
* 
* 


* 


ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 


ROWSIZE + 
(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx+2; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx+2; 
pDoc->m_playerY * ROWSIZE + pDoc->m_playerx+2; 
(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerXxt1; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerXxt+1; 

= pDoc->m_playerY * ROWSIZE + pDoc->m_playerxX+1; 


::CalcSouthView(int* blocks) 


// Calculate the visible blocks 


// player 


i 


blocks[@] = 
blocks[1] = 


blocks[2] 
blocks[3] 
blocks[4] 
blocks[5] 
blocks[6] 


s facing south. 
(pDoc->m_playeryY+3) 
(pDoc->m_playerY+3) 
(pDoc ->m_playerY+3) 
(pDoc ->m_playerY+3) 
(pDoc->m_playerY+3) 
(pDoc ->m_playerY+2) 
(pDoc ->m_playerY+2) 


when the 


+ + + +*+ F F 


ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 


+ pDoc->m_playerXx 
+ pDoc->m_playerx 
+ pDoc->m_playerx - 
+ pDoc->m_playerXx + 
+ pDoc->m_playerx; 
+ 
+ 
+ 
+ 
+ 


+.: 


pDoc->m_playerxX - 
pDoc->m_playerx + 
pDoc->m_playerx; 

pDoc->m_playerx - 
pDoc->m_playerx + 


+ pDoc->m_playerx+3; 
+ pDoc->m_playerx+3; 
+ pDoc->m_playerx+3; 
+ pDoc->m_playerx+3; 
pDoc ->m_playerXx+3; 


(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx; 


+ pDoc->m_playerXx + 
+ pDoc->m_playerx - 
+ pDoc->m_playerx + 
+ pDoc->m_playerX - 
+ pDoc->m_playerx; 

+ pDoc->m_playerx + 
+ pDoc->m_playerXx - 


blocks[7] 
blocks[8] 
blocks[9] 
blocks[10] = 
blocks[11] 
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(pDoc->m_playerY+2) * ROWSIZE + pDoc->m_playerx; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerX + 1; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx - 1; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx; 
pDoc->m_playerY * ROWSIZE + pDoc->m_playerxX + 1; 
blocks[12] = pDoc->m_playerY * ROWSIZE + pDoc->m_playerx - 1; 


+ pDoc->m_playerXx-3; 
+ pDoc->m_playerXx-3; 
+ pDoc->m_playerXx-3; 


+ pDoc->m_playerXx-3; 


pDoc ->m_playerx-3; 


+ pDoc->m_playerx-2; 


(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerxX-1 
(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerXx-1; 


(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx; 
(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx; 


J 


} 
void CAztecView: :CalcWestView(int* blocks) 
{ 
// Calculate the visible blocks when the 
// player is facing west. 
blocks[®] = (pDoc->m_playerY+2) * ROWSIZE 
blocks[1] = (pDoc->m_playerY-2) * ROWSIZE 
blocks[2] = (pDoc->m_playerY+1) * ROWSIZE 
blocks[3] = (pDoc->m_playerY-1) * ROWSIZE 
blocks[4] = (pDoc->m_playerY) * ROWSIZE + 
blocks[5] = (pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerXx-2; 
blocks[6] = (pDoc->m_playerY-1) * ROWSIZE 
blocks[7] = pDoc->m_playerY * ROWSIZE + pDoc->m_playerXx-2; 
blocks[8] = 
blocks[9] = 
blocks[10] = pDoc->m_playerY * ROWSIZE + pDoc->m_playerXx-1; 
blocks[11] = 
blocks[12] = 
} 


void CAztecView: :DrawView( ) 


{ 


// Return immediately if the game is over. 


if (m_gameOver) 


return; 


// Define coordinates for each of the 13 
// possible wall objects. 
UINT wallcoords[13][6] = 


{ 


}; 


O, 83, 242, 0, 31, 74, 
209, 83, 513, ©, 31, 74, 

9, 83, 274, 0, 81, 74, 

149, 83, 431, ©, 81, 74, 
83, 83, 356, 0, 74, 74, 

O, 68, 242, 87, 84, 104, 
156, 68, 432, 87, 84, 104, 
68, 68, 327, 87, 104, 104, 
O, 30, ©, 241, 69, 180, 
171, 30, 249, 241, 69, 180, 
30, 30, 70, 241, 178, 180, 
O, ©, 572, 146, 31, 240, 
209, ©, 604, 146, 31, 240 
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} 


// Get a pointer to the source bitmap's 

// BITMAPINFO structure. 

LPBITMAPINFO pBmInfo = 
m_pPartsDib->GetDibInfoPtr() ; 


// Copy the background scene to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, ©, @, 
m_pPartsDib, 0, @, 240, 240); 


// Check all 13 visible squares for objects. 
for (int i=@; i<13; ++i) 


{ 
// If the current square is a wall... 
if (m_objects[i] == Wall) 
// Copy the wall's image from the source 
// bitmap to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
wallcoords[i][@], wallcoords[i][1], 
m_pPartsDib, 
wallcoords[i][2], wallcoords[i][3], 
wallcoords[i][4], wallcoords[i][5]); 
} 


// If the player is on level 1, show the 
// appropriate horizon scene. 
if (pDoc->m_floorNum == 1) 

ShowScene() ; 


void CAztecView: :ShowScene() 


} 


UINT x, y; 


// Get the appropriate scene's coordinates 
// in the source bitmap. 
switch (pDoc->m_faceDir) 


{ 
case North: x = 454; y = 192; break; 
case East: x = 454; y = 276; break; 
case South: x = 454; y = 360; break; 
case West: x = 341; y = 360; break; 
} 


// Copy the horizon scene to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
64, ©, m_pPartsDib, x, y, 112, 83); 


void CAztecView: : InitNewGame ( ) 


} 


// Initialize the game-over flag. 
m_gameOver = FALSE; 


You'll learn about these functions later in this chapter. 
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This completes version 4 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 4 

Before running this version of Aztec Adventure, copy the LEVELO1B.BMP and 
LEVELO1.DUN files into your AZTEC directory. You'll find these files on this 
book’s CD-ROM in the CHAPO8\AZTEC4 directory. 


When you run the new version of Aztec Adventure, you see the window 
shown in figure 8.17. As you can see, the program now displays a 3-D view 
of the dungeon. This 3-D view is an accurate representation of where you’re 
standing in the dungeon at the beginning of a game. Because floor 1 of the 
dungeon is actually an outdoors setting, however, the dungeon doesn’t fade 
to darkness in the distance. Instead, a heavy mist prevents you from seeing 
any further than the three squares allowed in the rules you set up previously. 


Aztec Adventure x! Fig. 8.1 7 
= = oor zg 
| E ; pi APER | 


Version 4. 


As you know from the code you just placed in the program, the player starts 
off in column 1, row 1 of the dungeon. The dungeon data loaded into the 
program for floor 1 creates the dungeon grid shown in figure 8.18. The black 
dot is where you’re standing and the arrow shows the direction you're facing. 
As you can see, the 3-D view generated by the program shows exactly the 
right scene based on the dungeon grid. 
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Fig. 8.18 
A map of floor 1. 


PTT let 


Examining the LoadLevel() Function 

Dungeon layouts for each floor of Aztec Adventure are created by the Dun- 
geon Designer application. One of the first things that the Aztec Adventure 
application must do when it starts up is to load the data that defines the first 
floor of the dungeon. In addition, whenever the player moves from one floor 
of the dungeon to the next, the program must load the appropriate data for 
the new floor. The LoadLevel() function in the CAztecDoc class handles this 
task. 


LoadLevel() first obtains a pointer to the game’s current base file name: 
pFileName = m_pLevelFileName ->GetBuffer (12); 


The base file name, which is the string "LEVEL@1.DUN" at the start of the game, 
is held in a CString object pointed to by m_pLevelFileName. The CString mem- 
ber function GetBuffer() returns a pointer to this string. The function’s single 
argument is the size of the buffer needed to hold the string. 


Once the program has the file name, it calls the CFile object’s Open() member 
function to open the file: 


BOOL opened = file.Open(pFileName, CFile::modeRead) ; 
If the file opens okay, LoadLevel() constructs a CArchive object from the file: 
CArchive ar(&file, CArchive::load) ; 


A for loop reads in all 1,024 data items for the dungeon layout, constructs 
CItem objects from them, and adds each to the m_Dungeon array: 


for (int i=0; i<DUNGEONSIZE; ++i) 
{ 
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CItem* pItem = new CItem; 
ar >> pItem->iType; 
ar >> pItem->iNumber ; 
ar >> pItem->iValue; 
m_Dungeon.Add(pItem) ; 

} 


Finally, LoadLevel() closes the archive and the file: 


ar.Close(); 

file.Close(); 
The CAztecDoc class’s m_Dungeon array now contains pointers to each item in 
the dungeon grid. 


Examining the OnUpdate() Function 

As you learned previously in this book, the view class’s OnUpdate() function 
gets called whenever the document object calls its UpdateAllViews() function. 
In version 4 of Aztec Adventure, the CAztecDoc class calls UpdateAl1Views ( ) 
from the OnNewDocument() function, which is called whenever the game is 
started from the beginning, either when the program is first loaded or when 
the player selects the File menu’s New command. 


In Aztec Adventure, OnUpdate() first calls InitNewGame() to initialize the start- 
ing values of game variables. Currently, InitNewGame() simply sets the 
m_gameOver flag to FALSE. 


Because, when starting a new dungeon floor, the program may have already 
set up a WinG DC and bitmap based on the previous floor, OnUpdate() next 
calls DeleteWinGStuff () to delete any existing WinG DC and bitmap, and 
then calls SetupWinGStuff() to create a new WinG DC, bitmap, and identity 
palette based on the new floor’s color table: 


DeleteWinGStuff (); 
SetUpWinGStuf f () ; 


You may remember that each time the player moves in the dungeon, 

the program switches wall bitmaps to create the illusion of movement. 
OnUpdate() sets the pointer that holds the address of the next image to use 
to the “parts A” bitmap: 


m_pPartsDib = pDoc->m_pPartsADib; 
Next, OnUpdate() tells Windows to use the identity palette: 
CClientDC clientDC(this) ; 


SelectPalette(clientDC.m_hDC, m_hPalette, FALSE) ; 
RealizePalette(clientDC.m_hDC) ; 
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Finally, the program calculates and assembles the new view, and then calls 
Invalidate() to force the game’s main window to repaint itself: 
CalcView(FALSE) ; 


DrawView() ; 
Invalidate(FALSE) ; 


CalcView()’s argument of FALSE prevents the program from switching wall 
bitmaps yet again. Invalidate()’s FALSE argument keeps Windows from eras- 
ing the main window’s client area before doing the repainting. 


Examining the CalcView() Function 

Before Aztec Adventure can assemble the 3-D view that represents the player’s 
current location in the dungeon, it has to figure out exactly which squares in 
the grid are within view. As you know, the player can see up to 14 squares at 
a time. The CalcView() function determines, based on the player’s location, 
exactly what these squares are and what items they contain. 


The first thing CalcView() does is check the m_gameOver flag: 


if (m_gameOver) 
return; 
If the game is over, the program shouldn’t bother calculating a view. After all, 
there’s no view to see! If the game is over, then, CalcView() does nothing but 
return. Otherwise, the program uses a switch statement to call the appropri- 
ate function for the direction that the player is facing in the dungeon: 


switch (pDoc->m_faceDir) 


{ 
case North: CalcNorthView(blockNums); break; 
case West: CalcWestView(blockNums); break; 
case South: CalcSouthView(blockNums); break; 
case East: CalcEastView(blockNums); break; 
} 


The CalcNorthView(), CalcWestView(), CalcSouthView(), and CalcEastView() 
functions are where the program determines which squares are visible to the 
player. You’ll look at one of these functions later in this chapter. For now, 
just know that, upon return from one of these functions, the blockNums[ ] 
array contains the numbers of the 13 visible squares (not counting the square 
on which the player is standing). 


With the square numbers in hand, CalcView() next determines what items, 
if any, are in these visible squares. It does this with a for loop that iterates 
through the blockNums[] array: 


for (int i=@; i<13; ++i) 
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Within the loop, the program first checks that the square number stored in 
the blockNums[] array is valid: 
if ((blockNums[i] < ®) |; 
(blockNums[i] > DUNGEONSIZE -1) ) 
m_objects[i] = Empty; 
If the square number is invalid, the corresponding element of the m_objects[] 
array, which holds the item types for each visible square, is set to Empty. 


When would a square number not be valid? Suppose the player is facing 
north, standing in the square marked by the black box in figure 8.19. 


Se _ The player is Fig. 8.19 
standing here, A view that will 
facing north. create invalid 

squares in the 
blockNums[] array. 


As you can determine from the figure, the player can see a maximum of six 
squares: the square he’s standing on, the squares to his immediate left and 
right, and the row of three squares directly in front of him. The other squares 
would be outside the confines of the dungeon. In this case, the blockNums[ ] 
array will contain negative values for the invalid squares. If the reverse 

case were true, where the player was facing the southern-most wall, the 
blockNums[] array would contain values that were too large, and thus invalid. 


How about when the player is facing the western- or eastern-most walls? In 
those cases, the numbers in the blockNums[] array for the invalid squares will 
be “wrapped around” to the wrong rows. However, because the player is fac- 
ing a solid wall, the items that get drawn on-screen for these invalid squares 
always get hidden by the wall, so the program can just ignore these minor 
discrepancies. 


If the number in the currently indexed element of blockNums[] is valid, 
CalcView() gets the item type for the square and stores it in the m_objects[] 
array for later use by the program: 
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CItem* item = 
(CItem*) pDoc->m_Dungeon.GetAt(blockNums[i]) ; 
m_objects[i] = item->iType; 
Finally, it’s CalcView()’s job to switch between the wall-bitmap sets when 
appropriate. So, if toggleBMP is TRUE, the program determines which of the 
“parts A” and “parts B” bitmaps should be current, and sets the m_pPartsDib 
pointer appropriately: 


if (toggleBMP) 


if (m_pPartsDib == pDoc->m_pPartsADib) 
m_pPartsDib = pDoc->m_pPartsBDib; 
else 
m_pPartsDib = pDoc->m_pPartsADib; 
} 


Remember that it’s this bitmap switching that provides the illusion of move- 
ment as the player explores the dungeon. 


Examining the CalcNorthView() Function 

As I said previously, the CalcNorthView(), CalcWestView(), CalcSouthView(), 
and CalcEastView() functions are where the program determines which 
squares are visible to the player. These four functions all work similarly, so 
you'll examine only one, CalcNorthView(). 


In this function, blocks[0] through blocks[4] represent the five visible 
squares farthest from the player’s position. Because m_playerY contains the 
player’s current row number, subtracting three from it gives the number of 
the row that is three rows to the north. In a similar manner, adding or sub- 
tracting values from the player’s X position determines the column numbers 
of the five visible squares: 


blocks[@] = (pDoc->m_playerY-3) * ROWSIZE + pDoc->m_playerx - 2; 
blocks[1] = (pDoc->m_playerY-3) * ROWSIZE + pDoc->m_playerx + 2; 
blocks[2] = (pDoc->m_playerY-3) * ROWSIZE + pDoc->m_playerx - 1; 
blocks[3] = (pDoc->m_playerY-3) * ROWSIZE + pDoc->m_playerXx + 1; 
blocks[4] = (pDoc->m_playerY-3) * ROWSIZE + pDoc->m_playerx; 


The array elements blocks[5] through blocks[7] hold the numbers of the 
squares two rows to the north of the player position, so the row number is 
calculated by subtracting 2 from m_playery. The column numbers are again 
calculated by adding or subtracting from m_playerx. This time, however, there 
are only three columns: 


blocks[5] = (pDoc->m_playerY-2) * ROWSIZE + pDoc->m_playerx - 1; 
blocks[6] = (pDoc->m_playerY-2) * ROWSIZE + pDoc->m_playerXx + 1; 
blocks[7] = (pDoc->m_playerY-2) * ROWSIZE + pDoc->m_playerx; 
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The array elements blocks[8] through blocks[10] hold the numbers of the 
squares one row to the north of the player position, so the row number is 
calculated by subtracting 1 from m_playery. The column numbers are again 
calculated by adding to or subtracting from m_playerx. Again, only three 
columns are involved: 

blocks[8] (pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx - 1; 


blocks[9] (pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerXx + 1; 
blocks[1®] = (pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx; 


tou 


Finally, the array elements blocks[11] and blocks[12] represent the squares 
to the left and right of the player, in the same row as the player: 


blocks[11] pDoc->m_playerY * ROWSIZE + pDoc->m_playerx - 1; 
blocks[12] = pDoc->m_playerY * ROWSIZE + pDoc->m_playerX + 1; 


The program doesn’t need the number of the square in which the player is 
currently located, because this square can never contain an item. 


Examining the DrawView() Function 

After the program has determined which squares are visible and what items 
those squares contain, it can actually draw the 3-D view into the WinG 
bitmap. This task is performed by the DrawView() function. 


As with CalcView(), if the game is over, DrawVview() does nothing but return: 


if (m_gameOver) 
return; 


Otherwise, the function defines a two-dimensional array that holds the co- 
ordinates needed to draw each of the 13 possible wall items: 


UINT wallcoords[13][6] = 

{ 
0, 83, 242, 0, 31, 74, 
209, 83, 513, ©, 31, 74, 
9, 83, 274, 0, 81, 74, 
149, 83, 431, ©, 81, 74, 
83, 83, 356, 0, 74, 74, 
@, 68, 242, 87, 84, 104, 
156, 68, 432, 87, 84, 104, 
68, 68, 327, 87, 104, 104, 
0, 30, ©, 241, 69, 180, 
171, 30, 249, 241, 69, 180, 
30, 30, 70, 241, 178, 180, 
@, ©, 572, 146, 31, 240, 
209, ©, 604, 146, 31, 240 

}; 


Each row in the array contains six values. The first two are the coordinates 
where the wall image should be placed in the WinG bitmap. The next two 
values are the X,Y coordinates of the wall image within the source bitmap. 
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Finally, the last two values are the width and height of the wall image. 
These values will be used in a call to CopyDIBToWinG(). 


After initializing the array of coordinates, Drawview() gets a pointer to the 
source bitmap’s BITMAPINFO structure: 


LPBITMAPINFO pBmInfo = 
m_pPartsDib->GetDibInfoPtr() ; 


It then starts building the view by copying the background image to the 
WinG bitmap: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 0, 0, 
m_pPartsDib, @, 0, 240, 240); 
The program then uses a for loop to iterate through the m_objects[] array, 
which holds the item types for each of the visible squares: 


for (int i=@; i<13; ++i) 


Within the loop, Drawview() checks whether the currently indexed square 
contains a wall. If it does, the program blits the appropriate wall image to the 
WinG bitmap, using the current loop index to select the appropriate row of 
coordinates from the wallcoords[] array: 
if (m_objects[i] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 

wallcoords[i][®], wallcoords[i][1], 

m_pPartsDib, 

wallcoords[i][2], wallcoords[i][3], 

wallcoords[i][4], wallcoords[i][5]); 
Eventually, DrawView() will check for different item types, including doors, 
treasures, and monsters. For now, though, the function displays only walls. 


Finally, because the first floor of the dungeon is an outside scene that dis- 
plays different images on the horizon depending on which direction the 
player is facing, DrawView() calls the ShowScene() function if the current floor 
number is 1: 


if (pDoc->m_floorNum == 1) 
ShowScene(); 


Examining the ShowScene() Function 

This function, which displays a scene on the horizon when the player is on 
floor 1, is fairly simple. The function just uses the player’s facing direction 

in a switch statement to determine the position in the source bitmap of the 
appropriate horizon scene, and then calls CopyDIBToWinG() to blit the scene to 
the WinG bitmap. 
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The current version of Aztec Adventure now displays a 3-D, first-person view 
of your current location in the dungeon. There’s only one problem: The pro- 
gram starts you at column 1, row 1 in the dungeon, and you’ve got no way to 
move from that location. 


You could change the starting coordinates (stored in the CAztecDoc class’s 
m_playerX and m_playerY data members) and then recompile and rerun the 
program. Then, you’d see a new view based on your new location. However, 
it’d be a bit much to expect the player to recompile a program every time he 
wanted to move. Talk about a bad user interface! 


So, in this next version of Aztec Adventure, you'll enable the program to 
respond to keyboard commands. Specifically, when you’ve finished this 
section, you will be able to move around the dungeon by pressing your 
keyboard’s arrow keys. Writing the code that accomplishes this task is much 
easier than you might expect. The hardest part—writing the code that creates 
the view—is already done. To move through the dungeon, you have only to 
change the values in m_playerx and m_playery and then redraw the view. 


The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAPO8\AZTECS directory of this 
book’s CD-ROM. 


1. Load the AZTECVW.H file and add the following lines to the cAztecView 
class’s protected Implementation section, after the function declara- 
tions you placed there previously: 

void TurnRight(); 

void TurnLeft(); 

BOOL MoveForward() ; 

BOOL MoveBack(); 

void DoMove(); 
The preceding lines declare five new member functions for the 
CAztecView Class. 


2. Use ClassWizard to add an OnKeyDown() function to the CAztecView class, 
as shown in figure 8.20. 


The OnkeyDown() function responds to Windows’ WM_KEYDOWN message, 
which gets sent to the window whenever the user presses a key on the 
keyboard. You'll look at this function in greater detail later in this 
chapter. 
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Fig. 8.20 
Adding 
OnKeyDown() to 
the CAztecView 
class. 


ON_WM_CREATE 
ON_WM_DESTROY £ 


3. Add the following lines to the OnKeyDown() function, placing them right 
after the // TODO: Add your message handler code here and/or call 
default comment: 


// If the game is over, return immediately. 
if (m_gameOver) 
return; 


// Initialize the Boolean flag. 
BOOL moveOK = TRUE; 


// Perform the appropriate move based on the 
// key pressed. This function responds only to 
// the arrow keys. 

switch (nChar) 


{ 
case VK_LEFT: TurnLeft(); break; 
case VK_RIGHT: TurnRight(); break; 
case VK_UP: moveOK = MoveForward(); break; 
case VK_DOWN: moveOK = MoveBack(); break; 
default: moveOK = FALSE; 

} 


// If the requested move checks out okay, do it. 
if (moveOK) 
DoMove(); 


The preceding lines look only for the arrow keys, which indicate how 
the user wants to move. 


4. Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: : TurnLeft() 
{ 


} 


Creating Aztec Adventure, Version 5 


// Update the player's facing direction. 
switch(pDoc->m_faceDir) 


{ 
case North: pDoc->m_faceDir = West; break; 
case East : pDoc->m_faceDir = North; break; 
case South: pDoc->m_faceDir = East; break; 
case West : pDoc->m_faceDir = South; break; 
} 


void CAztecView: :TurnRight () 


{ 


} 


// Update the player's facing direction. 
switch(pDoc->m_faceDir) 


{ 
case North: pDoc->m_faceDir = East; break; 
case East : pDoc->m_faceDir = South; break; 
case South: pDoc->m_faceDir = West; break; 
case West : pDoc->m_faceDir = North; break; 
} 


BOOL CAztecView: :MoveForward() 


{ 


// Save the player's current position. 
UINT oldX = pDoc->m_playerx; 
UINT oldY = pDoc->m_playeryY; 


// Update the player's position based on 
// which direction he's facing. 
switch(pDoc->m_faceDir) 


{ 
case North: --pDoc->m_playerY; break; 
case East : ++pDoc->m_playerX; break; 
case South: ++pDoc->m_playerY; break; 
case West : --pDoc->m_playerX; break; 
} 


// Calculate the number of the square that 
// the player is about to move onto. 
UINT square = pDoc->m_playerY * ROWSIZE + pDoc->m_playerx; 


// Get the item stored in that square. 
CItem* item = (CItem*)pDoc->m_Dungeon.GetAt (square); 


// If the item is a wall, the player can't move there. 
if (item->iType == Wall) 
{ 

// Restore old player position. 

pDoc->m_playerX = oldX; 

pDoc->m_playerY = oldyY; 


// Indicate that the move failed. 
return FALSE; 
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} 


// Indicate that the move is okay. 
return TRUE; 


BOOL CAztecView: :MoveBack() 


{ 


} 


// Save the player's current position. 
UINT oldX = pDoc->m_playerx; 
UINT oldY = pDoc->m_playeryY; 


// Update the player's position based on 
// which direction he's facing. 
switch (pDoc ->m_faceDir ) 


{ 
case North: ++pDoc->m_playerY; break; 
case East : --pDoc->m_playerx; break; 
case South: --pDoc->m_playerY; break; 
case West : ++pDoc->m_playerX; break; 
} 


// Calculate the number of the square that 
// the player is about to move onto. 
UINT square = pDoc->m_playerY * ROWSIZE + pDoc->m_playerx; 


// Get the item stored in that square. 
CItem* item = (CItem*)pDoc->m_Dungeon.GetAt (square); 


// If the square isn't empty, 
// the player can't move there. 
if (item->iType != Empty) 


{ 
// Restore the player's old position. 
pDoc->m_playerXx = oldX; 
pDoc->m_playerY = oldyY; 
// Tell the calling function that the move failed. 
return FALSE; 

} 


// Tell the calling function that the move is okay. 
return TRUE; 


void CAztecView: :DoMove() 


{ 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Get a pointer to the source 
// bitmap's BITMAPINFO structure. 


} 


Creating Aztec Adventure, Version 5 


LPBITMAPINFO pBmInfo = 
m_pPartsDib ->GetDibInfoPtr(); 


// Calculate the new view and draw the 
// view on the WinG bitmap. 

CalcView( TRUE) ; 

DrawView(); 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Blit the WinG bitmap to the window. 
WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, ©, 0); 


You'll learn about these functions later in this chapter. 


This completes version 5 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 


application. 


Running Aztec Adventure, Version 5 

When you run this version of Aztec Adventure, the window starts off 
looking the same as it did in the last version of the program. However, you 
can change the view by pressing your keyboard’s arrow keys, which has 
the following effects: 


Key Effect 

Up arrow Move forward 
Down arrow Move back 
Left arrow Turn left 
Right arrow Turn right 


As you can see in figure 8.21, you can now move from your starting position 
in the dungeon, exploring to your heart’s content. 
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Fig. 8.21 
Exploring the 
dungeon 


Aztec Adventure 


Examining the OnKeyDown() Function 

In a Windows program, whenever the user presses a key on his keyboard, 
Windows sends a WM_KEYDOWN message to the application’s window. An MFC 
program can respond to this message by providing an OnKeyDown() function. 


Take a look at CAztecView’s version of OnKeyDown(). Because you don’t want 
the player to try to move around the dungeon after the game is over, 
OnKeyDown() first checks the m_gameOver flag and returns if the flag is TRUE: 


if (m_gameOver) 
return; 


Otherwise, the program initializes the moveOk flag: 
BOOL moveOK = TRUE; 


Then, a switch statement using OnKeyDown()’s nChar parameter routes the 
keystroke to the appropriate function: 


switch(nChar) 

{ 
case VK_LEFT: TurnLeft(); break; 
case VK_RIGHT: TurnRight(); break; 
case VK_UP: moveOK = MoveForward(); break; 
case VK_DOWN: moveOK = MoveBack(); break; 
default: moveOK = FALSE; 
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The parameter nChar contains a virtual key code, which is a value that specifies 
a particular keystroke. You can look up other virtual key codes in Visual C++’s 
documentation. In Aztec Adventure, though, you’re concerned only with the 
arrow keys, which have virtual key codes of VK_LEFT, VK_RIGHT, VK_UP, and 
VK_DOWN. If nChar doesn’t contain one of these four codes, the program sets 
moveOK to FALSE. Otherwise, the TurnLeft(), TurnRight(), MoveForward(), Or 
MoveBack() function gets called to make sure the player’s move is valid and, 

if so, to update the player’s position. 


If moveOK retains its TRUE value, OnKeyDown() calls the DoMove() function to 
perform the actual move: 


if (moveOK) 
DoMove() ; 


Examining the TurnLeft() Function 

When the user presses the left- or right-arrow key on his keyboard, Aztec 
Adventure responds by turning the player 90 degrees in the requested direc- 
tion. Accomplishing this turn is painfully easy, as shown in the TurnLeft () 
function. 


If you look at the function, you can see that TurnLeft() simply checks the 
player’s current facing direction and then sets the new direction. The next 
time the view gets drawn in the window, this new direction is used to deter- 
mine what squares the player can see. The TurnRight() function works simi- 
larly, so there’s no need to go over it here. 


Examining the MoveForward() Function 

When the player presses his keyboard’s up-arrow key, Aztec Adventure moves 
the player forward one square in whatever direction the player is currently 
facing. The player’s new location is calculated by the MoveForward() function. 


First, MoveForward() saves the player’s current position in case it must be 
restored later: 


li 


UINT oldX pDoc->m_playerX; 
UINT oldY = pDoc->m_playerY; 


Next, the program uses a switch statement to check the player’s current 
facing direction and update his position accordingly: 


switch(pDoc->m_faceDir) 

{ 
case North: --pDoc->m_playerY; break; 
case East : ++pDoc->m_playerX; break; 
case South: ++pDoc->m_playerY; break; 
case West : --pDoc->m_playerX; break; 
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After updating the player’s coordinates in the grid, the program calculates the 
number of the destination square: 


UINT square = pDoc->m_playerY * ROWSIZE + pDoc->m_playerXx; 


This value is then used as an index into the m_Dungeon array, in order to 
retrieve the item located in the player’s destination square: 


CItem* item = (CItem*)pDoc->m_Dungeon.GetAt (square); 


Because the player cannot move through a wall, MoveForward() checks the 
item type. If the item for the player’s new destination square contains a wall, 
the program restores the player’s old position and returns FALSE from the 
function: 


if (item->iType == Wall) 


{ 
pDoc->m_playerX = oldX; 
pDoc->m_playerY = oldY; 
return FALSE; 

} 


If the player’s destination square is okay, MoveForward() returns TRUE, indicat- 
ing that the program can now move the player to his new destination: 


return FALSE; 


Eventually, MoveForward() will also check for other items in the player’s 
destination square, including doors, monsters, and treasures. 


The MoveBack() function works similarly to MoveForward(), except it will allow 
the player to move back only if the destination square is empty. This prevents 
the player from backing into items he can’t see behind him, such as treasure 
chests and—heaven forbid!—prowling monsters. 


Examining the DoMove() Function 

Once the program has determined that it’s okay for the player to move into 
the destination square, it calls the DoMove() function to perform the actual 
move. Of course, nothing actually moves. Instead, DoMove() simply creates a 
new view based on the player’s new location in the dungeon grid and then 
blits this new view to the display. 


First, DoMove() gets a DC for the window: 
CClientDC clientDC(this) ; 


Next, it gets a pointer to the source bitmap’s BITMAPINFO structure: 


LPBITMAPINFO pBmInfo = 
m_pPartsDib ->GetDibInfoPtr() ; 
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Then, DoMove() calls CalcView() and DrawView() to create the new view in the 
WinG bitmap: 

CalcView(TRUE) ; 

DrawView(); 


Notice that CalcView()’s single argument is TRUE, which means it should 
toggle between the “parts A” and “parts B” bitmaps. 


Then, in preparation for blitting the new view, the program selects and 
realizes the identity palette: 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 
Finally, DoMove() blits the newly modified WinG bitmap to the window’s 
client area: 


WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, ©, @); 
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Because this is a Windows game, the player will probably want to use his 
mouse. (In fact, most players of DOS games want to use a mouse, too.) One 
obvious way to use a mouse is to enable the player to click on buttons that 
perform the same functions as the keyboard’s arrow keys. That is, the game 
should have buttons that move the player through the dungeon. In this ver- 
sion of the program, you'll add those buttons, as well as begin to create the 
game’s final display. 


The complete source code and executable file for this step in the creation of the 
Aztec Adventure application are in the CHAPO8\AZTEC6 directory of this book’s 
CD-ROM. 


1. Load the AZTECDOC.H file and add the following lines to the 
CAztecDoc Class’s public Attributes section, after the data members you 
placed there previously (make sure you place the lines in the public 
section and not after the protected keyword): 

CDib* m_pPanelDib; 
CDib* m_pSundryDib; 


BYTE* m_pPanelBits; 
BYTE* m_pSundryBits; 
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These lines add four data members to the class. 


Load the AZTECDOC.CP?P file and add the following lines to the 
CAztecDoc class’s constructor, after the code you placed there previously: 
m_pPanelDib = new CDib("panel.bmp") ; 
m_pSundryDib = new CDib("sundry.bmp") ; 


m_pPanelBits = m_pPanelDib->GetDibBitsPtr () ; 
m_pSundryBits = m_pSundryDib->GetDibBitsPtr () ; 


The first two lines construct CDib objects from the PANEL.BMP and 
SUNDRY.BMP bitmap files. The PANEL.BMP file contains Aztec 
Adventure’s main screen, whereas SUNDRY.BMP contains many smaller 
images that the program needs throughout the game. The second two 
lines acquire pointers to each bitmap’s image data. 


In the CAztecDoc class’s destructor, add the following lines, after the 
code you placed there previously: 


delete m_pPanelDib; 
delete m_pSundryDib; 


These lines delete the new CDib objects created in the constructor. 


Load AZTECVW.H and add the following lines to the CAztecView class's 
protected Attributes section, after the data declarations you placed 
there previously: 


BOOL m_forwardButtonPressed; 
BOOL m_backButtonPressed; 
BOOL m_leftButtonPressed; 
BOOL m_rightButtonPressed; 


These lines add four protected data members to the CAztecView class. 


Also in AZTECVW.H, add the following lines to the CAztecView class’s 
protected Implementation section, after the function declarations you 
placed there previously: 


void DisplayCompass(CDC* pDC) ; 

void HandleForwardButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void HandleBackButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void HandleLeftButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void HandleRightButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void DoForwardButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void DoBackwardButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 
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void DoLeftButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void DoRightButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 


The preceding lines declare new member functions for the CAztecView 
class. 


Load AZTECVW.CPP and add the following lines to the CAztecView 
class’s OnDraw() function, right before the call to WinGBitB1t(): 

// Get a pointer to the panel bitmap's 

// BITMAPINFO structure. 


BITMAPINFO* pDibInfo = 
pDoc ->m_pPanelDib->GetDibInfoPtr() ; 


// Blit the panel onto the window. 
StretchDIBits(pDC->m_hDC, ©, 0, 540, 420, 
©, ©, 540, 420, pDoc->m_pPanelBits, pDibInfo, 
DIB_RGB_COLORS, SRCCOPY) ; 


DisplayCompass (pDC) ; 


The preceding code blits to the screen the image contained in the CDib 
object, which was constructed from the PANEL.BMP file. This image is 
the window’s main display. The call to DisplayCompass() displays the 
on-screen compass in the correct orientation based on the direction the 
player is facing. 


Still in AZTECVW.CPP, add the following lines to the CAztecView class’s 
OnCreate() function, right after the lines you placed there previously: 
m_forwardButtonPressed = FALSE; 
m_backButtonPressed = FALSE; 
m_leftButtonPressed = FALSE; 
m_rightButtonPressed = FALSE; 


SetClassLong(m_hWnd, GCL_STYLE, 
CS_HREDRAW ; CS_VREDRAW) ; 


The first four preceding lines initialize the flags that the program uses to 
track the state of the movement buttons. The last line resets the view 
window’s WNDCLASS structure to disallow double-clicks. Normally, the 
window’s class data structure includes the CS_DBLCLKs bit flag, which 
allows the window to receive double-clicks. But catching double-clicks 
makes Aztec Adventure’s on-screen movement buttons clumsy to use. 
This is because two quick clicks on a movement button will be inter- 
preted as a double-click rather than two movement commands, making 
the buttons seem unresponsive. Turning off the window’s double-click 
mechanism solves this problem. 
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8. Use ClassWizard to add an OnLButtonDown() function to the CAztecView 
class, as shown in figure 8.22. 


Fig. 8.22 
Adding 
OnLButtonDown() 
to the CAztecView 
class. 


9. Add the following code to the OnLButtonDown() function, right after the 
// TODO: Add your message handler code here and/or call default 
comment: 


// If the game is over, return immediately. 
if (m_gameOver) 
return; 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// Clicked on forward button? 
if ((point.x > 184) && (point.x < 234) && 
(point.y > 296) && (point.y < 330)) 
HandleForwardButton(clientDC, pBmInfo) ; 


// Clicked on backward button? 
else if ((point.x > 184) && (point.x < 234) && 
(point.y > 336) && (point.y < 368)) 
HandleBackButton(clientDC, pBmInfo) ; 
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// Clicked on left button? 
else if ((point.x > 128) && (point.x < 178) && 
(point.y > 296) && (point.y < 368)) 
HandleLeftButton(clientDC, pBmInfo) ; 


// Clicked on right button? 
else if ((point.x > 240) && (point.x < 290) && 
(point.y > 298) && (point.y < 368)) 
HandleRightButton(clientDC, pBmInfo) ; 


The OnLButtonDown() function responds to the WM_LBUTTONDOWN message, 
which Windows sends to the program whenever the user left-clicks 
inside the application’s window. You'll look at this function in detail 
later in this chapter. 


10. Use ClassWizard to add an OnLButtonUp() function to the CAztecView 
class, as shown in figure 8.23. 


Fig. 8.23 
Adding 
OnLButtonUp() to 
the CAztecView 
class. 


WM_MOUSEMOVE 
WM_MOVE 


WM_PAINT 
WM_RBUTTONDBLI 


11. Add the following code to the OnLButtonUp() function, right after the 
// TODO: Add your message handler code here and/or call default 
comment: 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source 
// bitmap's BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib->GetDibInfoPtr() ; 
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// If the forward button is depressed... 
if (m_forwardButtonPressed) 
DoForwardButton(clientDC, pBmInfo) ; 


// ...else if the backward button is depressed... 
else if (m_backButtonPressed) 
DoBackwardButton(clientDC, pBmInfo) ; 


// ...else if the left button is depressed... 
else if (m_leftButtonPressed) 
DoLeftButton(clientDC, pBmInfo) ; 


// ...else if the right button is depressed. 
else if (m_rightButtonPressed) 
DoRightButton(clientDC, pBmInfo) ; 


The OnLButtonUp() function responds to the WM_LBUTTONUP message, 
which Windows sends to the program whenever the user releases the 
left mouse button. You'll look at this function in detail later in this 
chapter. 


12. Add the following lines to the end of the DoMove() function, right after 
the call to WinGBitB1t(): 


// Update the compass face. 
DisplayCompass (&clientDC) ; 


The preceding code calls the function that displays the appropriate 
compass face on-screen. 


13. Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :DoForwardButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
// Draw the button in its unselected form. 
StretchDIBits(clientDC.m_hDC, 
183, 297, 52, 34, 
108, 182, 52, 34, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


// Turn off the button's flag. 
m_forwardButtonPressed = FALSE; 


// Release the mouse capture. 
ReleaseCapture(); 


// Check whether it's okay to move forward. 
BOOL moveOK = MoveForward() ; 


// If it is okay, do it. 
if (moveOK) 
DoMove(); 
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void CAztecView: :DoBackwardButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 


{ 
StretchDIBits(clientDC.m_hDC, 
183, 335, 52, 34, 
@, 182, 52, 34, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
m_backButtonPressed = FALSE; 
ReleaseCapture(); 
BOOL moveOK = MoveBack() ; 
if (moveOK) 
DoMove(); 
} 


void CAztecView: :DoLeftButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
StretchDIBits(clientDC.m_hDC, 
127, 297, -52,.° 72, 
@, 108, 52, 72, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
m_leftButtonPressed = FALSE; 
ReleaseCapture() ; 
TurnLeft(); 
DoMove() ; 
} 


void CAztecView: :DoRightButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
StretchDIBits(clientDC.m_hDC, 
239, 297, 52, 72, 
108, 108, 52, 72, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
m_rightButtonPressed = FALSE; 
ReleaseCapture(); 
TurnRight() ; 
DoMove() ; 


} 


void CAztecView: :HandleForwardButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
// Blit the depressed button image to the window. 
StretchDIBits(clientDC.m_hDC, 
183, 297, 52, 34, 
162, 182, 52, 34, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


// Set the button flag. 
m_forwardButtonPressed = TRUE; 
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// Capture the mouse. 
SetCapture(); 
} 


void CAztecView: :HandleBackButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
StretchDIBits(clientDC.m_hDC, 
183, 335, 52, 34, 
54, 182, 52, 34, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
m_backButtonPressed = TRUE; 
SetCapture() ; 
} 


void CAztecView: :HandleLeftButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
StretchDIBits(clientDC.m_hDC, 
127, 297, 52, 72, 
54, 108, 52, 72, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
m_leftButtonPressed = TRUE; 
SetCapture(); 
} 


void CAztecView: :HandleRightButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
StretchDIBits(clientDC.m_hDC, 
239, 297, 52, 72, 
162, 108, 52, 72, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_ COLORS, SRCCOPY) ; 
m_rightButtonPressed = TRUE; 
SetCapture() ; 
} 


void CAztecView: :DisplayCompass(CDC* pDC) 
{ 
// Get a pointer to the source 
// bitmap's BITMAPINFO structure. 
BITMAPINFO* pDibInfo = 
pDoc->m_pSundryDib->GetDibInfoPtr() ; 


UINT x; 
// Get the coordinates of the appropriate compass 


// face based on the player's facing direction. 
switch (pDoc->m_faceDir) 


{ 
case North: x = 0; break; 
case West x = 60; break; 
case South: x = 120; break; 
case East x = 180; 
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// Select and realize the palette. 
SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 
RealizePalette(pDC->m_hDC) ; 


// Blit the compass face onto the window. 
StretchDIBits(pDC->m_hDC, 58, 309, 58, 58, 
x, 218, 58, 58, pDoc->m_pSundryBits, pDibInfo, 
DIB_RGB_COLORS, SRCCOPY) ; 
} 


You'll examine these functions later in this chapter. 


This completes version 6 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 6 

Before running this version of Aztec Adventure, copy the PANEL.BMP and 
SUNDRY.BMP files into the same directory with the program. You'll find 
these files in the CHAPO8\AZTEC6 directory of this book’s CD-ROM. 


When you run Aztec Adventure now, you see the window shown in figure 
8.24. The game’s main screen is really starting to look like something now! 
Although things such as the player figure and the player statistics are still 
missing from the display, the new buttons and compass work fine. To prove 
it, click a button. Notice that if you turn, so does the compass. 


Fig. 8.24 


dungeon. 


Exploring the 
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Examining the OnLButtonDown() Function 

In Aztec Adventure, the buttons that control the player’s movement look 
nothing like conventional Windows buttons. They’ve been drawn in such a 
way that they fit in with the rest of the display graphics. Although Visual C++ 
has a special class for user-drawn buttons, that class doesn’t handle 256-color 
bitmaps. Because Aztec Adventure’s display is 256-color, the program must 
handle these specially drawn buttons on its own, without help from Visual 
C++’s classes. 


As it turns out, however, handling the buttons is no big deal. The program 
must simply watch for the user’s left mouse button to go down and up. 
When the left mouse button goes down, the program checks whether the 
mouse pointer is over one of the movement buttons in the display. If so, 
the program must swap the button’s bitmap so that it looks pressed. The 
OnLButtonDown() function, which responds to Windows’ WM_LBUTTONDOWN 
message, handles this task. 


First, OnLButtonDown() checks the m_gameOver flag, because you don’t want the 
player to try and move around the dungeon when the game is over: 


if (m_gameOver) 
return; 


Next, the program gets a DC for the window: 
CClientDC clientDC(this) ; 


To make sure the button bitmaps are drawn with the correct colors, the 
program selects and realizes the identity palette: 


SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


Next, OnLButtonDown() gets a pointer to the source bitmap’s BITMAPINFO struc- 
ture (the button images are contained in the SUNDRY.BMP file): 


BITMAPINFO* pBmInfo = 
pDoc ->m_pSundryDib->GetDibInfoPtr() ; 


Next, the program checks the coordinates of the mouse click, to see whether 
the user clicked on the forward button: 
if ((point.x > 184) && (point.x < 234) && 
(point.y > 296) && (point.y < 330)) 
HandleForwardButton(clientDC, pBmInfo) ; 
If the mouse-click coordinates fall inside the button’s coordinates, the 
user is trying to click the button, in which case the program calls 
HandleForwardButton() to animate the button and perform the user’s 
command. 
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The other buttons are handled similarly, checking their coordinates against 
those of the mouse click: 


else if ((point.x > 184) && (point.x < 234) && 
(point.y > 336) && (point.y < 368) ) 
HandleBackButton(clientDC, pBmInfo); 
else if ((point.x > 128) && (point.x < 178) && 
(point.y > 296) && (point.y < 368) ) 
HandleLeftButton(clientDC, pBmInfo) ; 
else if ((point.x > 240) && (point.x < 290) && 
(point.y > 298) && (point.y < 368)) 
HandleRightButton(clientDC, pBmInfo) ; 


Examining the HandleForwardButton() Function 

Each of the movement buttons has its own function—HandleForwardButton(), 
HandleBackButton(), HandleRightButton(), Or HandleLeftButton()—that 
handles that button if the user clicks on it. Because these four functions work 
similarly, you’ll examine only HandleForwardButton(). 


This function first blits the pressed-button image to the window: 


StretchDIBits(clientDC.m_hDC, 
183, 297, 52, 34, 
162, 182, 52, 34, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


Then it sets the m_forwardButtonPressed flag to TRUE and calls the function 
SetCapture() to force all mouse messages to be sent to this window: 
m_forwardButtonPressed = TRUE; 
SetCapture(); 


SetCapture() is an MFC function based on a Windows API function of the 
same name. 


Normally, mouse messages are sent to the window over which the mouse pointer is 
located when the message is generated. However, there are times when a window 
must get every mouse message, no matter where the mouse pointer is located. 
Suppose, for example, that the player clicked on the forward button, held the left 
mouse button down, moved the mouse out of the game’s window, and then re- 
leased the left mouse button. In thi ae the gamen window would never receive the 


pressed image. By calling the SetCapture() Here Aztec Adventure ensures that 
it won't miss such important messages. 
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Examining the OnLButtonUp() Function 

When the player releases the left mouse button, Windows sends a 
WM_LBUTTONUP message. Because the program called SetCapture(), the 
WM_LBUTTONUP message gets sent to Aztec Adventure’s window no matter 
where the mouse pointer is located when the message is generated. 
The OnLButtonUp() function handles the WM_LBUTTONUP message. 


Because this function needs to restore the button’s unpressed image, it first 
gets a DC for the window: 


CClientDC clientDC(this) ; 
It then selects and realizes the identity palette: 


SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


The program also gets a pointer to the source bitmap’s BITMAPINFO structure: 


BITMAPINFO* pBmInfo = 
pDoc ->m_pSundryDib->GetDibInfoPtr() ; 


The program then checks each button’s flag to see which button was pressed. 
The appropriate function gets called, sending along the window’s DC and the 
pointer to the source bitmap’s BITMAPINFO structure: 
if (m_forwardButtonPressed) 
DoForwardButton(clientDC, pBmInfo) ; 
else if (m_backButtonPressed) 
DoBackwardButton(clientDC, pBmInfo); 
else if (m_leftButtonPressed) 
DoLeftButton(clientDC, pBmInfo) ; 


else if (m_rightButtonPressed) 
DoRightButton(clientDC, pBmInfo) ; 


As you can see, each button has its own function—DoForwardButton(), 
DoBackwardButton(), DoLeftButton(), Or DoRightButton()—to restore the 
button’s image and to perform the selected command. 


Examining the DoForwardButton() Function 

The DoForwardButton(), DoBackwardButton(), DoLeftButton(), and 
DoRightButton() functions all work similarly, so you’ll examine only 
DoForwardButton() here. 


DoForwardButton() first restores the button’s unpressed image, using the DC 
and the BITMAPINFO pointer passed into the function as parameters: 


StretchDIBits(clientDC.m_hDC, 
183, 297, 52, 34, 
108, 182, 52, 34, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
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Next, DoForwardButton() turns off the m_forwardButtonPressed flag and re- 
leases the mouse capture, so other windows can receive mouse messages: 


m_forwardButtonPressed = FALSE; 
ReleaseCapture() ; 


Just as if the user has pressed his keyboard’s up-arrow key, DoForwardButton() 
calls MoveForward() to modify and validate the player’s new position in the 
dungeon grid: 


BOOL moveOK = MoveForward() ; 


Finally, if the Boolean value returned from MoveForward() is TRUE, indicating 
that the player is able to move forward into the next square, the program 
calls DoMove() to update the 3-D view: 


if (moveOK) 
DoMove(); 


Examining the DisplayCompass() Function 

The last function of interest in this version of Aztec Adventure is 
DisplayCompass(), which keeps the compass on the main display oriented to 
the player’s facing direction. 


DisplayCompass() first gets a pointer to the source bitmap’s BITMAPINFO struc- 
ture (the four compass images are contained in the SUNDRY.BMP file): 


BITMAPINFO* pDibInfo = 
pDoc->m_pSundryDib->GetDibInfoPtr() ; 


It then uses a switch statement to check the player’s current facing direction 
and sets the X coordinate for the compass image within the bitmap. (Because 
the compass bitmaps are in a row, their Y coordinates are all the same.) 


switch (pDoc->m_faceDir) 


{ 
case North: x = 0; break; 
case West : x = 60; break; 
case South: x = 120; break; 
case East : x = 180; 

} 


Finally, the function selects and realizes the identity palette and blits the 
appropriate compass image to the screen: 


SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 
RealizePalette(pDC->m_hDC) ; 
StretchDIBits(pDC->m_hDC, 58, 309, 58, 58, 
x, 218, 58, 58, pDoc->m_pSundryBits, pDibInfo, 
DIB_RGB_COLORS, SRCCOPY) ; 
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Summary 


Generating the 3-D view for Aztec Adventure is much easier than you might 
imagine. This is because the player’s view is limited by a number of rules. 
The player can see only three squares ahead, can face only in four directions, 
must jump from the center of one square to the center of the next, and has 
limited peripheral “vision.” 


By using these rules, a maximum of 14 squares at a time are visible to the 
player. This means that any view of the dungeon walls can be assembled 
from only 13 wall images. (There can never be a wall in the player’s square, so 
a 14th wall image isn’t needed.) By blitting these images from back to front, 
and from the outside to the center, any view of the dungeon is easily created. 
In the next chapter, you learn how to display other objects such as doors and 
treasure chests in the 3-D view. 


Chapter 9 
Placing Objects in th 
Dungeon 


At this point in Aztec Adventure, you can wander around a 3-D dungeon 
maze, using either your mouse or your keyboard to control the action. Unfor- 
tunately, walking around an empty dungeon gets boring fast. The whole 
point of Aztec Adventure is, after all, to find treasures and fight creatures. 
How can you find things that don’t appear in the 3-D view? 


In this chapter, you enable Aztec Adventure to display such objects as trea- 
sure chests and doors. When you’re done, you'll be able to not only see items 
in the dungeon, but also interact with them. You'll be able to pick up keys, 
weapons, shields, elixir, and gold, as well as open doors—if you have the 
right key. 
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Your first task is to get Aztec Adventure to display dungeon objects in its 3-D 
view. You'll worry about how to interact with those items later in this chap- 
ter. Although Aztec Adventure’s dungeons can contain treasure, weapons, 
armor, elixir, and keys, in order to keep the display routines simpler, all these 
items are represented by a treasure chest. When you pick up a treasure chest, 
you discover what it contains. . 


Doors also appear in the dungeon. However, because doors can be seen only 
when the player is facing them, they’re a bit more difficult to handle in the 
program, as you'll soon see. 
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The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAPO9\AZTEC7 directory of this 
book’s CD-ROM. 


1. Load the AZTECVW.CPP file and add the following lines to the 
end of the second if statement in the DrawView() function, 
right after the second call to CopyDIBToWinG() but before the if 
statement’s closing brace: 


else if (m_objects[i] == Door) 
ShowDoor (i); 

else if (m_objects[i] == Treasure) 
ShowTreasure (i); 

else if (m_objects[i] == Potion) 
ShowTreasure (i); 

else if (m_objects[i] == Sword) 
ShowTreasure(i) ; 

else if (m_objects[i] == Armor) 
ShowTreasure (i) ; 


else if (m_objects[i] == Key) 
ShowTreasure (i); 


These lines call the appropriate functions to display the type of object 
located in the dungeon square that is currently indexed by i. 


2. Add the following functions to the end of AZTECVW.CPP: 


void CAztecView: :ShowDoor(UINT objectNum) 
{ 
switch (objectNum) 
{ 
case 0: 
if (m_objects[2] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
©, 88, m_pPartsDib, 
610, 388, 10, 63); 
break; 
case 1: 
if (m_objects[3] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
230, 88, m_pPartsDib, 
596, 388, 10, 63); 
break; 
case 2: 
if (m_objects[4] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
19, 88, m_pPartsDib, 
574, 388, 66, 63); 
break; 


} 
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case 3: 
if (m_objects[4] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
155, 88, m_pPartsDib, 
574, 388, 66, 63); 
break; 
case 4: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
87, 88, m_pPartsDib, 
574, 388, 66, 63); 
break; 
case 5: 
if (m_objects[7] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
®, 78, m_pPartsDib, 
555, 0, 77, 86); 
break; 
case 6: 
if (m_objects[7] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
162, 78, m_pPartsDib, 
545, 0, 77, 86); 
break; 
case 7: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
77, 78, m_pPartsDib, 
545, 0, 86, 86); 
break; 
case 8: 
if (m_objects[10] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
@, 52, m_pPartsDib, 
396, 192, 50, 136); 
break; 
case 9: 
if (m_objects[10] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
189, 52, m_pPartsDib, 
319, 192, 51, 136); 
break; 
case 10: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
52, 52, m_pPartsDib, 
319, 192, 134, 136); 


void CAztecView: :ShowTreasure(UINT objectNum) 


{ 


int coords[13][6] = 


{ 


@, ©, 0, ©, 0, @, 
©, ©, 0, ©, 0, @, 

21, 140, 78, 446, 30, 12, 
185, 140, 78, 446, 30, 12, 


102, 140, 78, 446, 30, 12, 
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©, 160, 92, 423, 35, 21, 
204, 160, 78, 423, 35, 21, 
90, 160, 78, 423, 49, 21, 
O, 180, 56, 423, 20, 43, 
220, 180, ©, 423, 20, 43, 
82, 180, ©, 423, 76, 43, 
o, ©, ©, ©, O, @, 

o, 0, 0, 0, 0, Ø 

}; 


CopyDIBToWinGTrns((BYTE*)m_pWinGDibBits, 
coords[objectNum][@], 
coords[objectNum][1], 
m_pPartsDib, 
coords[objectNum] [2], 
coords[objectNum] [3], 
coords[objectNum] [4], 
coords[objectNum][5], 253); 

} 


void CAztecView: :CopyDIBToWinGTrns 
(BYTE* m_pWinGDibBits, UINT dstX, UINT dstyY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmw, 
UINT frmH, UINT trnsColor) 


{ 
// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight() ; 
// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr(); 
// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=@; col<frmW; ++col) 
{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmX; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstxX; 
if (pDibBits[srcIndex] != trnsColor) 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex]; 
} 
} 


These functions display treasure chests and doors in the dungeon’s 3-D 
view. You'll look at these functions in detail later in this chapter. 
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3. Load the AZTECVW.H file and add the following lines to the CAztecView 
class’s protected Implementation section, after the function declara- 
tions you placed there previously: 

void CopyDIBToWinGTrns(BYTE* m_pWinGDibBits, 
UINT dstX, UINT dstY, CDib* pDib, UINT frmx, 
UINT frmY, UINT frmW, UINT frmH, UINT trnsColor) ; 


void ShowDoor(UINT objectNum) ; 
void ShowTreasure(UINT objectNum) ; 


These lines declare several functions as protected member functions of 
the CAztecView class. 


This completes version 7 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 7 

Before running this version of Aztec Adventure, you must copy a new 
LEVELO1.DUN file into your AZTEC project directory. You'll find this file 
on this book’s CD-ROM in the CHAPO9\AZTEC7 directory. 


When you run the new version of Aztec Adventure, press your keyboard’s up- 
arrow key and start moving east. You’ll soon see the view shown in figure 9.1. 


Aztec Adventure ES cs Sie BEE Fig. 9.1 
A treasure chest in 
the dungeon. 
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Fig. 9.2 
A dungeon 
doorway. 


As you can see, the program displays treasure chests for many of the objects 
you can place in the dungeon. It can also display doors. To prove this, move 
farther east until you see an opening on your right. Then, turn to face the 
opening, and you'll see the display shown in figure 9.2. 


Examining the ShowTreasure() Function 

As I mentioned previously, in order to simplify the display of objects in the 
dungeon, all inanimate objects (except doors) appear as treasure chests. It’s 
not until you open the chest that you know whether you’ve found a weapon, 
armor, gold, elixir, or a key. The ShowTreasure() function, which follows, is 
responsible for displaying the chests in the program’s 3-D view. 


Displaying a treasure chest is just a matter of calling the CopyDIBToWinGTrns() 
function with the correct coordinates. The coordinates needed by the func- 
tion are found in the coords array: 


int coords[13][6] = 
{ 


J 

3 3 
21, 140, 78, 446, 30, 12, 
185, 140, 78, 446, 30, 12, 
102, 140, 78, 446, 30, 12, 
©, 160, 92, 423, 35, 21, 
204, 160, 78, 423, 35, 21, 
90, 160, 78, 423, 49, 21, 
@, 180, 56, 423, 20, 43, 
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220, 180, 0, 423, 20, 43, 

82, 180, ©, 423, 76, 43, 

0, ©, 0, ©, ©, 0, 

0, ©, 0, 0, 0, © 

}; 

This array’s values are arranged such that each row represents the coordinates 
for a particular square of the dungeon grid. You saw this technique used in 
the previous chapter, “The Pseudo 3-D Viewpoint,” when you displayed walls 
in the 3-D view. Notice that four of the data lines contain all zeroes. This is 
because treasure chests cannot appear in the dungeon squares represented by 
those lines. 


You learned about the CopyDIBToWinGTrns() function back in Chapter 4, “Pro- 
gramming with WinG.” You may remember that this function enables you to 
copy an image containing a transparent color, which is a color that does not 
appear in the destination bitmap. Because the treasure-chest image is not 
rectangular, you must use CopyDIBtoWinGTrns() to display it. Otherwise, the 
areas surrounding the chest’s image will overwrite part of the 3-D view. In the 
ShowTreasure() function, the call to CopyDIBToWinGTrns() looks like this: 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 

coords[objectNum][@], 

coords[objectNum][1], 

m_pPartsDib, 

coords[objectNum][2], 

coords[objectNum][3], 


coords[objectNum][4], 
coords[objectNum][5], 253); 


Examining the ShowDoor() Function 

Unfortunately, displaying a door is not as simple as displaying a treasure 
chest. With the chest, you can take a slight liberty with the laws of physics 
and have the chest always facing the player, no matter which direction the 
player is looking. A door, on the other hand, can’t appear to be facing the 
player when it’s not. This rule makes the ShowDoor() function more complex 
than ShowTreasure(). 


Why does the ShowDoor() function need to be so complicated? To understand 
the problem, compare how you display a treasure chest with how you must 
display a door. Suppose the player has the dungeon view represented by the 
squares in figure 9.3. In the figure, the circle is the player, the arrow is the 
player’s facing direction, and the small black square is a treasure chest. With 
this dungeon configuration, the player can see the treasure chest. Because the 
chest has no facing direction in the dungeon, it doesn’t matter whether the 
player is looking north, south, east, or west. As long as the treasure chest is in 
front of the player, it will appear as though the player is facing it. 
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Fig. 9.3 

A dungeon view 
containing a 
treasure chest. 


Fig. 9.4 

A dungeon view 
containing a door 
facing the player. 


Fig. 9.5 

The dungeon view 
created by the 
arrangement 
shown in figure 
9.4. 


What if the small, black square in figure 9.3 is a door rather than a treasure 
chest? If the door is facing the player, as shown in figure 9.4, the player 
would be able to see the door, as shown in figure 9.5. 


One thing you should notice about figure 9.5 is that the player must be fac- 
ing a wall in order for the door to be facing him, too. A door can’t just appear 
in midair, after all (at least not in this dungeon). It must be supported by wall 
blocks on both sides. This is a key factor in figuring out which way a door is 
facing. 


Now, suppose the door is facing away from the player, as shown in figure 9.6. 
Because the door must be sandwiched between two walls, the player must 
have the view shown in figure 9.7. If the player takes a step forward, closer to 
the door, he still shouldn’t be able to see the door, as shown in figure 9.8. In 
other words, when a door is not facing the player, the door’s image is always 
blocked by a wall. 
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Fig. 9.6 

A dungeon view 
with a door not 
facing the player. 


Fig. 9.7 

The dungeon view 
created by the 
arrangement 
shown in figure 
9.6. 


Fig. 9.8 

The dungeon view 
when the player 
takes a step for- 
ward, closer to the 
door. 


How can you figure out which way a door is facing? Easy! Just check to see 
where the door’s supporting walls are. If they lie on the left and right of the 
door relative to the player’s facing direction, the door is facing the player. 
Keep in mind, though, that the 13 images that make up a dungeon view are 
assembled from outside-in and from front to back, yielding a numbering 
scheme like that shown in figure 9.9. 
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Fig. 9.9 
The numbering of 
dungeon squares. 


Using figure 9.9 as a guide, if a door is in square 6, it will be facing the player 
only if there’s a wall in square 7. Similarly, if there’s a door in square 2, it will 
be visible to the player only if there’s a wall in square 4. In the ShowDoor() 
function, the latter statement translates into the following code: 
case 2: 
if (m_objects[4] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
19, 88, m_pPartsDib, 
574, 388, 66, 63); 
break; 
Each of the 13 squares in the player’s current view has its own case clause. 
Each clause checks the direction of a door by looking for walls in the appro- 
priate places. If the wall isn’t there, the door doesn’t get drawn. The only 
exceptions are the face-on situations of squares 4, 7, and 10. In these cases, 
the door is always drawn. Why? If there’s a door facing away from the player 
in square 7, the player won’t see it anyway, because there must be a wall in 
square 10, and that wall will cover the door’s image. Ditto for square 4. In the 
case of square 10, a door there will always be facing the player, because if it 
weren't, the player would be standing in a square that contains a wall, which 
is an impossible situation. 


t ough such a door would ordinarily be pretty useless — ( 
_walk around it—you could use a door like this as some sort of magical entrywa 
_ transports the player to some other location or triggers some other action. You’d 
have to handle the door as a special case in the program, of course. 
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Wandering around your dungeon sure is a lot more fun now that you can see 
the objects you placed there. Still, it would be even better if you could inter- 
act with those objects. Treasure chests are, of course, supposed to be opened, 
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as are doors, for that matter. In this section, then, you’ll add the code that 
enables the player to open treasure chests. You’ll take care of opening doors 
later in the chapter. 


The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAPO9\AZTECS8 directory of this 
book’s CD-ROM. 


1. Load the AZTECDOC.H file and add the following lines to the 

CAztecDoc class’s public Attributes section, after the lines you 
placed there previously: 

BOOL m_keys[6]; 

UINT m_potionValues[6]; 

UINT m_potionCount ; 

CDib* m_pMessageDib; 
These lines declare four data members of the CAztecDoc class. The pro- 
gram needs these data members to keep track of keys and elixir, as well 
as to display special message boxes when the player opens treasure 
chests. The m_potionCount variable holds the number of elixir bottles 
the player has, the m_potionValues[] array stores the healing values of 
any elixir the player has, and the m_keys[] array stores Boolean values 
indicating which keys the player has in his possession. The CDib object 
pointed to by m_pMessageDib contains the bitmap loaded from the 
MESSAGE.BMP file. 


2. Load the AZTECDOC.CPP file and add the following line to the 
CAztecDoc class's constructor, after the m_pSundryDib = new 
CDib("sundry.bmp") line you placed there previously: 


m_pMessageDib = new CDib("message.bmp") ; 


This line loads the bitmap that contains the message boxes the player 
sees whenever he opens treasure chests. 


3. Add the following line to the CAztecDoc class’s destructor, after the 
delete m_pSundryDib line you placed there previously: 


delete m_pMessageDib; 
This line deletes the bitmap that contains the message boxes. 


4. Still in the AZTECDOC.CPP file, add the following lines to the 
OnNewDocument() function, after the m_faceDir = East line you placed 
there previously: 
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m_potionCount = 0; 


for (UINT i=@; i<6; ++i) 


{ 


} 


m_keys[i] = FALSE; 
m_potionValues[i] = 0; 


These lines initialize the new data members. 


5. Load the AZTECVW.CPP file and comment out the MoveForward() 
function. Replace that function with the version that follows: 


BOOL CAztecView: :MoveForward() 


{ 


// Initialize temporary variables for the 
// player's new position. 

UINT newX = pDoc->m_playerx; 

UINT newY = pDoc->m_playeryY; 


// Update the player's position based on 
// which direction he's facing. 
switch(pDoc->m_faceDir) 


{ 
case North: newY = pDoc->m_playerY - 1; break; 
case East : newX = pDoc->m_playerX + 1; break; 
case South: newY = pDoc->m_playerY + 1; break; 
case West : newX = pDoc->m_playerX - 1; break; 
} 


// Calculate the number of the square that 
// the player is about to move onto. 
UINT square = newY * ROWSIZE + newX; 


// Get the item stored in that square. 
CItem* pItem = (CItem*)pDoc->m_Dungeon.GetAt (square); 


// If the item is a wall, the player can't move there. 
if (pItem->iType == Wall) 
return FALSE; 
else if (pItem->iType == Key) 
{ 
pItem->iType = Empty; 
GetKey (pItem->iNumber) ; 
return FALSE; 


else if (pItem->iType == Potion) 
{ 
pItem->iType = Empty; 
GetPotion(pItem->iValue) ; 
return FALSE; 


else if (pItem->iType == Sword) 
{ 
pItem->iType = Empty; 
GetSword(pItem->iValue) ; 
return FALSE; 


}; 
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else if (pItem->iType == Armor) 


{ 
pItem->iType = Empty; 
GetArmor (pItem->iValue); 
return FALSE; 

} 

else if (pItem->iType == Treasure) 

{ 
pItem->iType = Empty; 
GetTreasure(pItem->iValue) ; 
return FALSE; 

} 


// Set the player's new position in the dungeon. 
pDoc->m_playerX = newX; 
pDoc->m_playerY = newyY; 


// Indicate that the move is okay. 
return TRUE; 


The new MoveForward() function not only enables the player to move 
forward, but it also determines whether the player is trying to open a 
treasure chest. If the player tries to move forward onto a square contain- 
ing a treasure chest, MoveForward() checks to see what item the chest 
contains, and then calls the appropriate function to give that item to 
the player. 


6. Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :GetKey(UINT number) 


{ 


} 


// Tell the player he found a key. 
ShowMessage (Key) ; 


// Record the key in the key array. 
pDoc->m_keys[number] = TRUE; 


void CAztecView: :GetPotion(UINT value) 


{ 


} 


// Tell the player what he found. 
ShowMessage (Potion); 


// If there's room for another potion... 
if (pDoc->m_potionCount < 6) 


{ 

// Increment the potion count. 

++pDoc ->m_potionCount; 

// Record the potion's value. 

pDoc ->m_potionValues[pDoc->m_potionCount-1] = value; 
} 


void CAztecView: :GetSword(UINT value) 


{ 
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// Tell player what he found. 
ShowMessage (Sword) ; 
} 


void CAztecView: :GetArmor(UINT value) 


// Tell the player what he found. 


ShowMessage (Armor); 
} 
void CAztecView: :GetTreasure(UINT value) 
{ 
// Tell the player that he found some treasure. 
ShowMessage (Treasure); 
} 
void CAztecView: :ShowMessage(UINT type) 
{ 
// Get the DC for the window. 
CClientDC clientDC(this) ; 
// Select and realize the identity palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 
UINT x, y; 
switch(type) 
{ 
case Treasure: x = 0; y = 0; break; 
case Armor: x = 164; y = 0; break; 
case Key: xX = 0; y = 94; break; 
case Potion: x = 164; y = 94; break; 
case Sword: x = 0; y = 188; break; 
} 
// Copy the message to the WinG bitmap. 
CopyDIBToWinG((BYTE*)m_pWinGDibBits, 
10, 10, pDoc->m_pMessageDib, 
x, y, 165, 94); 
// Display the scene. 
WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, @, 0); 
} 


You'll look at these functions later in the chapter. 


7. Load the AZTECVW.H file and add the following lines to the CAztecView 
class’s protected Implementation section, after the lines you placed 
there previously: 

void GetKey(UINT number) ; 
void GetPotion(UINT value); 


void GetSword(UINT value) ; 
void GetArmor(UINT value); 
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void GetTreasure(UINT value) ; 

void ShowMessage(UINT type) ; 
These lines declare the new functions as member functions of the 
CAztecView class. 


This completes version 8 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 8 

Before you run this version of Aztec Adventure, copy the MESSAGE.BMP file 
into your AZTEC directory. This file is located on this book’s CD-ROM, in the 
CHAPO9\AZTECS directory. 


When you run the new version of Aztec Adventure, press your keyboard’s up- 
arrow key and start moving east. You’ll soon stumble upon the treasure chest 
that you saw when running version 7 of the program. When you get to the 
chest, move forward as though you want to step into the same square as the 
chest. When you do, a message box appears, telling you what’s in the chest 
(see fig. 9.10). 
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chest. 


Examining the GetTreasure() Function 

Because Aztec Adventure doesn’t yet handle player statistics, finding a trea- 
sure chest filled with gold doesn’t do much for the player. In fact, as you can 
see from the GetTreasure() function, handling the chest currently requires 
only a single function call: 
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Opening a treasure 
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ShowMessage (Treasure); 


The call to ShowMessage() displays the message you saw when you opened the 
chest. Because the MoveForward() function previously set the square to Empty, 
the chest will never appear again. 


In this version of Aztec Adventure, the GetSword() and GetArmor() functions 
work in exactly the same way as GetTreasure(). These functions will be 
beefed up later in this book. 


Examining the ShowMessage() Function 
The ShowMessage() function, too, is pretty simple. The function first acquires 
a device context for the view window’s client area: 


CClientDC clientDC(this) ; 
It then calls SelectPalette() and RealizePalette() to set up the colors 
properly: 


SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


A switch statement then gets the coordinates within the MESSAGE.BMP 
file for the appropriate message box, depending on the function’s type 
parameter: 


UINT x, Yy; 

switch(type) 

{ 
case Treasure: x = 0; y = 0; break; 
case Armor: x = 164; y = 0; break; 
case Key: x = 0; y = 94; break; 
case Potion: x = 164; y = 94; break; 
case Sword: x = 0; y = 188; break; 


} 
Next, ShowMessage() blits the message box’s image to the WinG bitmap: 


CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
10, 10, pDoc->m_pMessageDib, 
xX, y, 165, 94); 
Finally, the WinGBitB1t() function blits the WinG bitmap to the window’s 
display: 


WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, ©, 2); 


Examining the GetPotion() Function 

The GetPotion() function is a little more complex because there are values 
the program must store in the document class’s data members whenever the 
player picks up an elixir. 
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First, the function tells the player what he’s found: 
ShowMessage(Potion) ; 


Next, GetPotion() checks that the user doesn’t already have the maximum 
number of elixir bottles: 


if (pDoc->m_potionCount < 6) 


If the player already has six elixir bottles, the treasure chest disappears and 
the elixir is wasted. (So, the clever player with six elixir bottles will use one 
elixir bottle before opening a treasure chest, thus ensuring that there’s room 
for another bottle if there’s one in the chest.) If the player has room for more 
elixir, GetPotion() updates the player’s elixir count and stores the elixir’s 
value (which determines how much the elixir heals the player when the elixir 
is used): 

++pDoc ->m_potionCount ; 

pDoc ->m_potionValues[pDoc->m_potionCount-1] = value; 
The GetKey() function works similarly, storing the key that the user found in 
the m_keys[] array. 
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Even though you can now pick up items you find in the dungeon, the pro- 
gram doesn’t display those items in your inventory. As you roam around 
opening treasure chests, you’ll soon forget exactly what you have. Of course, 
you shouldn’t have to keep track of such things, anyway, when the program 
is perfectly capable of doing it for you. In this section, then, you'll add the 
functions and data needed to display the objects that you gather. 


The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAPO9\AZTEC9 directory of this 
book’s CD-ROM. 


1. Load the AZTECDOC.H file and add the following lines to the class’s 
public Attributes section, after the lines you placed there previously: 


UINT m_curSword; 
UINT m_curArmor; 
BOOL m_hasSword; 
BOOL m_hasArmor; 
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These lines declare public data members for the CAztecDoc class. These 
data members keep track of the player’s weapons and armor. 


Load the AZTECDOC.CPP file and add the following lines to the 
OnNewDocument() function, right after the m_potionCount = 0 line you 
placed there previously: 


m_curSword = 0; 
m_curArmor = 0; 
m_hasSword = FALSE; 
m_hasArmor = FALSE; 


These lines initialize the new data members at the beginning of each 
new game. 


Load the AZTECVW.CP?P file and add the following lines to the 
OnDraw() function, right after the DisplayCompass() line you placed 
there previously: 

DisplayBody () ; 

DisplayKeys() ; 

DisplayPotions() ; 
These lines call the functions that display various graphical elements on 
the main display. 


Add the following lines to the end of the GetKey() function: 


// Update the key display. 
DisplayKeys() ; 


The call to the DisplayKeys() function displays images representing the 
keys the player has in his possession. 


Add the following lines to the end of the GetPotion() function: 


// Update the potion display. 

DisplayPotions() ; 
The call to the DisplayPotions() function displays images representing 
the elixir bottles the player has in his possession. 


Add the following lines to the end of the GetSword() function: 


// Set the sword flag. 
pDoc->m_hasSword = TRUE; 


// Show new body with sword. 

DisplayBody() ; 
These lines set the document class’s sword flag, indicating that the 
player now has a sword. It also calls DisplayBody(), a function that 
draws the warrior’s body image in the upper right corner of the main 
display. 
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7. Add the following lines to the end of the GetArmor() function: 


// Set the shield flag. 
pDoc->m_hasArmor = TRUE; 


// Show new body with shield. 
DisplayBody() ; 


These lines set the document class’s armor flag, indicating that the 
player now has some form of armor. It also calls DisplayBody() to draw 
the Aztec warrior’s body image. 


8. Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :DisplayKeys() 
{ 
// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// Display up to six keys. 
for (UINT i=0; i<6; ++i) 
{ 
// If the player has this key, show it. 
if (pDoc->m_keys[i]) 
StretchDIBits(clientDC.m_hDC, 
311 4 -i *32, 297, 32, 32, 
0, 448 - i * 34, 32, 32, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


} 


void CAztecView: :DisplayPotions() 
{ 
// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Erase the current potion display. 
clientDC.SelectStock0Object(BLACK_BRUSH) ; 
ClientDC.Rectangle(312, 351, 502, 384); 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 
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// Display the player's potions. 
for (UINT i=0; i<pDoc->m_potionCount; ++i) 
StretchDIBits(clientDC.m_hDC, 
311 + i * 32, 351, 32; 32, 
102, 380, 32, 32, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
} 


void CAztecView: :DisplayBody() 
{ 
// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source bitmap's 

// BITMAPINFO structure. 

BITMAPINFO* pBmInfo = 
pDoc->m_pSundryDib->GetDibInfoPtr() ; 


// If the user has no sword or shield, 
// display the normal body. 
if ((!pDoc->m_hasSword) && (!pDoc->m_hasArmor) ) 
StretchDIBits(clientDC.m_hDC, 
392, 52, 48, 87, 
152, 291, 48, 87, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


// Otherwise, display the battle-ready body. 
else 
StretchDIBits(clientDC.m_hDC, 
392, 52, 48, 87, 
102, 291, 48, 87, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


// Display the player's sword and shield. 
DisplaySword(&clientDC) ; 
DisplayArmor (&clientDC) ; 

} 


void CAztecView: :DisplaySword(CClientDC* pClientDC) 
{ 
// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 
pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// If the player has a sword, show it. 
if (pDoc->m_hasSword) 
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StretchDIBits (pClientDC ->m_hDC, 
381, 46, 27, 93, 
202+ (pDoc->m_curSword)*29, 285, 27, 93, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
} 


void CAztecView: :DisplayArmor(CClientDC* pClientDC) 
{ 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// If the player has a shield, show it. 
if (pDoc->m_hasArmor) 
StretchDIBits(pClientDC->m_hDC, 
421, 68, 32, 32, 
136+(pDoc->m_curArmor)*34, 448, 32, 32, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
} 


You'll look at these functions later in this chapter. 


9. Load the AZTECVW.H file and add the following lines to the CAztecView 
class’s protected Implementation section, after the function declara- 
tions you placed there previously: 

void DisplayKeys() ; 
void DisplayPotions() ; 
void DisplayBody() ; 


void DisplaySword(CClientDC* pClientDC) ; 
void DisplayArmor(CClientDC* pClientDC) ; 


The preceding lines declare the new functions as member functions of the 
CAztecView class. 


This completes version 9 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 9 

Before you run the program, you must copy a new version of LEVELO1.DUN 
into your AZTEC project directory. This file can be found on this book’s 
CD-ROM, in the CHAPO9\AZTEC9 directory. 


When you run the new version of Aztec Adventure, you'll see the window 
shown in figure 9.11. As you can see, the dungeon corridor now contains 
several treasure chests. Move forward to collect their contents. As you do, 
the objects appear on the screen as shown in figure 9.12. 
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Fig. 9.11 
Treasure chests 
in the dungeon 
corridor. 


The contents | 
of the chests 
displayed on 


| 
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| 
the screen. | 

| Weapons and 

1 

| 
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armor appear 
here. 


Keys and elixir 
appear here. 


Examining the DisplayKeys() Function 

Drawing the items on the screen as the player picks them up is basically a 
simple process. You only blit the appropriate image to a specific location in 
the application’s window. For keys, this task is accomplished by the 
DisplayKeys() function. 
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void CAztecView: :DisplayKeys() 


{ 
// Get a DC for the window. 


CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// Display up to six keys. 
for (UINT i=@; i<6; ++i) 


{ 
// If the player has this key, show it. 


if (pDoc->m_keys[i]) 
StretchDIBits(clientDC.m_hDC, 
311 + i * 32, 297, 32, 32, 
@, 448 - i * 34, 32, 32, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


} 


DisplayKeys() creates a device context, selects and realizes the identity pal- 
ette, gets a pointer to the source bitmap’s BITMAPINFO structure, and then uses 
StretchDIBits() in a loop to display on the screen the keys that the player 
has in his possession: 


for (UINT i=; i<6; ++i) 


// If the player has this key, show it. 
if (pDoc->m_keys[i]) 
StretchDIBits(clientDC.m_hDC, 
311 + i * 32, 297, 32, 32, 
@, 448 - i * 34, 32, 32, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
} 


Because the loop variable i not only controls the loop but also represents the 
key numbers from 0 to 5, it’s used in StretchDIBits() in the calculation for 
the destination rectangle’s X coordinate (311 + i * 32). 


The DisplayPotions(), DisplayBody(), DisplaySword(), and DisplayArmor() 
functions all work similarly to DisplayKeys(). In DisplayBody(), however, 
the program chooses between two different body types—“at ease” or “on 
guard”—depending on whether the player has a sword and a shield. Also, 
DisplaySword() and DisplayArmor() are called by DisplayBody() and receive 
a reference to the DC created in DisplayBody(). 
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You can now see the items you collect in the dungeon, which is a great help 
in knowing how well you're doing in the game. When you pick up an elixir 

bottle, weapon, or shield, it appears on the screen. When you discover a key, 
it pops up in its correct place in the key area of the display. 


However, you still can’t use the keys. That is, in the current version of Aztec 
Adventure, you can walk right through every door in your path. As you 
know, in the final game, you’re not supposed to be able to go through a door 
until you have the right key. In this section, you’ll add the code that controls 
this aspect of the game. Moreover, you'll add a simple animation to the 
game, so that the doors actually appear to slide open, rather than just 
disappear. 


The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAPO9\AZTEC10 directory of this 
book’s CD-ROM. 


1. Load the AZTECVW.CPP file and add the following lines to the 
MoveForward() function at the end of the if statement, right before the 
// Set the player's new position in the dungeon comment you 
placed there previously. (Make sure you place the lines in the new 
MoveForward() function and not in the one you commented out.) 


else if (pItem->iType == Door) 


{ 
if (pDoc->m_keys[pItem->iNumber ] ) 
{ 
pItem->iType = Empty; 
OpenDoor () ; 
} 
return FALSE; 
} 


The preceding lines check for a door in the square into which the player 
is trying to move. If there is a door, the program checks whether the 
player has the right key to open the door. If he does, the call to the 
OpenDoor() function performs the opening-door animation. 


2. Add the following function to the end of the AZTECVW.CP? file: 


void CAztecView: :OpenDoor () 


{ 
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// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the identity palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Set standard door coordinates. 
UINT dstY = 52; 
UINT dibY 193; 
UINT dibH = 135; 


// Set special door coordinates for floor 1. 
if (pDoc->m_floorNum == 1) 


{ 
dstY = 99; 
dibY = 239; 
dibH = 89; 
} 


// Perform four frames of animation. 
for (int i=; i<4; ++i) 


{ 
// Calculate and redraw the 3-D view. 
CalcView(FALSE) ; 
DrawView() ; 
// Display door parts every frame except the last. 
if (i < 3) 
{ 
// Show the left side of the opening door. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
52, dstY, m_pPartsDib, 
334+i*15, dibY, 52-i*15, dibH); 

// Show the right side of the opening door. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
134+i*15, dstY, m_pPartsDib, 

386, dibY, 52-i*15, dibH); 
} 
// Display the new 3-D scene. 
WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, 0, 0); 
} 


} 


This is the function that performs the opening-door animation. You'll 
look at it in detail later in this chapter. 


3. Load the AZTECVW.H file and add the following line to the protected 
Implementation section, after the function declarations you placed 
there previously: 


void OpenDoor() ; 
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This line declares OpenDoor() as a member function of the CAztecView 
class. 


This completes version 10 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 10 

Before you run the program, you must copy a new version of LEVELO1.DUN 
into your AZTEC project directory. This file can be found on this book’s 
CD-ROM, in the CHAPO9\AZTEC10 directory. 


When you run the new version of Aztec Adventure, you'll see the familiar 
dungeon corridor. Walk eastward until you’re standing right in front of a 
treasure chest. Don’t open the chest yet. Instead, turn to the right to face the 
door there. Try to go through the door. Nothing happens. Now, get the key 
from the treasure chest and again try to go through the door. When you do, 
the door slides open and lets you through. 


Examining the OpenDoor() Function 

Although the effect is cool, the animation of the door opening is easy to do. 
Essentially, the program displays smaller and smaller parts of the doors until 
the doors are gone completely. The function that handles the animation is 
OpenDoor(). 


As any function that displays graphics on the screen must do, OpenDoor() first 
creates a DC for the window, and then selects and realizes the identity pal- 
ette. Then, because doors in the first dungeon floor are a different size than 
doors on other levels, the function must set dstY, dibY, and dibH to different 
values, depending on the current floor number: 

// Set standard door coordinates. 

UINT dstY = 52; 


UINT dibY 193; 
UINT dibH 135; 


ou 


// Set special door coordinates for floor 1. 
if (pDoc->m_floorNum == 1) 


{ 
dstY = 99; 
dibY = 239; 
dibH = 89; 


Summary 


After setting the coordinates, the function sets up a for loop to perform a 
four-frame animation: 


for (int i=@; i<4; ++i) 
Within the loop, the program first redraws the 3-D view, this time without 
the door (because MoveForward() has already set the door square to Empty): 


CalcView(FALSE) ; 
DrawView() ; 


Then, the program checks whether the for loop’s control variable is less 
than 3: 


if (i < 3) 


If it is, OpenDoor() draws two segments of the door image on the left and right 
of the door’s enclosing walls: 

// Show the left side of the opening door. 

CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 


52, dstY, m_pPartsDib, 
334+i*15, dibY, 52-i*15, dibh); 


// Show the right side of the opening door. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
134+i*15, dstY, m_pPartsDib, 
386, dibY, 52-i*15, dibH); 
As you can see, the loop-control variable i is used to help calculate how 
much of the door images to show and where to draw the images. The higher 
the value of i, the smaller the portions of the door images that are drawn. 
When i becomes 3, the program redraws the 3-D scene without the doors. 


Summary 


You’ve learned that displaying objects in the dungeon is just a matter of 
checking the m_Dungeon array to see what each square in the current view 
contains and then blitting the appropriate image to the screen. Most objects 
in the dungeon can be viewed from any angle, which makes displaying them 
much simpler. Doors, however, should be seen by the player only when he’s 
facing them. By checking a door’s connecting walls, you can tell the door’s 
facing direction and decide whether or not to draw it. 


Picking up objects in the dungeon is as easy as setting the object’s entry in 
the m_Dungeon array to Empty and then redrawing the 3-D scene without the 
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object. Of course, you have to add the object to the player’s inventory, which 
you do by updating the appropriate variables and displaying the object’s 
image in the correct place on the display. 


There’s still one important object missing from the dungeon: monsters! What 
fun would a dungeon adventure be without a few ugly creatures looking to 
reduce the player to Aztec burgers? In Chapter 11, you’ll add these unsavory 
creatures to your evolving Aztec Adventure game. But first, in the next chap- 
ter, you’ll add player statistics, which enable the player to check on his 
progress in the game. 


Chapter 10 
Incorporatin 
Statistics 


As you play Aztec Adventure, you gather items, fight monsters, and find your 
way through the dungeon maze. Most of these activities have some effect on 
your alter ego in the game. For example, finding a treasure not only adds gold 
to your inventory, but also increases your experience. Fighting a monster 
increases your experience, but decreases your hit points. To restore your hit 
points, you must use elixir. 


Your state in the game at any given time is represented by a set of numbers 
called player statistics. In a full-fledged role-playing game (RPG), a character 
may have dozens of statistics, including not only obvious things such as hit 
points and experience, but also strength, intelligence, luck, personality, con- 
stitution, and any number of other attributes. Often such games also give 
your character many skills, such as lock picking, fighting, swimming, map 
reading, stealing, spell casting, and more, all of which can be improved in 
the game. It’s these attributes and skills that define a character in an RPG. 


To keep things simple (and to keep the publication date of this book some- 
time during this century), Aztec Adventure handles only a few player statis- 
tics. As you already know, these statistics include level, experience, hit points, 
gold, weapon, and defense. In this chapter, you’ll add these player statistics 
to the game, bringing you one step closer to completing Aztec Adventure. 
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Adding player statistics to a game requires creating program variables to hold 
the statistics. As the player interacts with the game environment, the pro- 
gram updates these variables to reflect the player’s current status. Of course, 
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the player usually likes to be kept advised of these changes. For example, 

the player needs to know how many hit points he has left so that he knows 
whether it’s time to use elixir. This means that you must display player statis- 
tics on the screen. In this section, you add to the document class the vari- 
ables that will hold the values of the player’s statistics. You’ll also add code 
to the view class—code that will display those statistics on the screen. 


The eopiplete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAP1 O\AZTEC11 directory of this 
book’s CD-ROM. 


1. Load the AZTECDOC.H file and add the following lines to the 
CAztecDoc Class’s public Attributes section, after the lines you placed 
there previously: 

UINT m_playerLevel; 

UINT m_playerGold; 

UINT m_playerExper; 

UINT m_playerDefense; 

UINT m_playerAttack; 

int m_playerHP; 
These lines declare the variables that represent the player’s statistics as 
public data members of the CAztecDoc class. The variables must be de- 
clared as public so that the CAztecView class, which must manipulate 
the variables, can access them. 


2. Load the AZTECDOC.CPP file and add the following lines to the 
OnNewDocument() function, right after the for loop’s closing brace: 
// Initialize player statistics. 
m_playerLevel = 1; 
m_playerGold = 0; 
m_playerExper = 0; 
m_playerHP = 100; 
m_playerDefense = Q; 
m_playerAttack = Q; 
These lines initialize the player’s statistics at the beginning of each new 
game. 


3. Load the AZTECVW.CPP file and add the following line to the OnDraw() 
function, after the DisplayPotions() line you placed there previously: 


DisplayStats(); 
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This line calls the function that displays the player’s statistics on the 


screen. 


4. Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :DisplayStats() 


{ 


} 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select a black brush. 
clientDC.SelectStockObject (BLACK_BRUSH) ; 


// Erase the old stats. 
for (UINT i=; i<6; ++i) 


clientDC.Rectangle(470, 159+1i*20, 502, 


175+i*20) ; 


// Create and display the statistics text strings. 


char s[10]; 
clientDC.SetTextColor(RGB(255,0,0)); 
clientDC.SetBkColor(RGB(0,@,0)); 
wsprintf(s, "%d", pDoc->m_playerLevel) ; 
clientDC.TextOut(470, 159, s, strlen(s)); 
wsprintf(s, "%d", pDoc->m_playerExper) ; 
clientDC.TextOut(470, 179, s, strlen(s)); 
wsprintf(s, "%d", pDoc->m_playerHP) ; 
clientDC.TextOut(47®, 199, s, strlen(s)); 
wsprintf(s, "%sd", pDoc->m_playerGold) ; 
clientDC.TextOut(47®, 219, s, strlen(s)); 
wsprintf(s, "%sd", pDoc->m_playerAttack) ; 
clientDC.TextOut(47@, 239, s, strlen(s)); 
wsprintf(s, "%sd", pDoc->m_playerDefense) ; 
clientDC.TextOut(470, 259, s, strlen(s)); 


void CAztecView: :UpdateExper(int exp) 


{ 


} 


pDoc->m_playerExper += pDoc->m_floorNum * exp; 


CheckLevel(); 


void CAztecView: :CheckLevel() 


{ 


// Get the player's current experience. 
UINT experience = pDoc->m_playerExper; 


// Get the experience needed to attain the next level. 
UINT experNeeded = m_nextLevel[pDoc->m_playerLevel-1]; 


// If the player has enough experience, advance 


// him to the next level. 
if (experience >= experNeeded) 


{ 
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MessageBox("Your level is increased", "Level", MB_ OK); 
pDoc->m_playerLevel += 1; 
DisplayStats(); 


} 


These functions handle the player statistics. You’ll look at them in de- 
tail later in this chapter. 


5. Add the following lines to the end of the GetKey() function: 


// Add to player's experience. 
UpdateExper (2) ; 


// Show new statistics. 

DisplayStats(); 
These lines increase the player’s experience whenever he finds a key. 
Notice that whenever the player’s statistics change, the program calls 
DisplayStats() to display the new statistics. 


6. Add the following lines to the end of the GetPotion() function: 


// Add to player's experience. 
UpdateExper (2) ; 


// Show new statistics. 

DisplayStats(); 
These lines increase the player’s experience whenever he finds an elixir 
bottle. 


7. Add the following lines to the GetSword() function, right before the call 
to the DisplayBody() function: 


// Update the player's attack statistic. 
pDoc->m_playerAttack = value; 


// Record the player's new weapon type. 
pDoc ->m_curSword = pDoc->m_floorNum - 1; 


// Add to player's experience. 
UpdateExper (2) ; 


// Display new statistics. 

DisplayStats(); 
These lines increase the player’s attack power and experience whenever 
he finds a weapon. The m_playerAttack statistic is equal to the item 
value you gave the weapon when you designed the dungeon. The 
m_curSword variable determines which weapon image to display on the 
screen. 


8. 


10. 
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Add the following lines to the GetArmor() function, right before the call 
to the DisplayBody() function: 


// Update the player's defense statistic. 
pDoc->m_playerDefense = value; 


// Record the player's new armor type. 
pDoc->m_curArmor = pDoc->m_floorNum - 1; 


// Add to player's experience. 
UpdateExper (2) ; 


// Display new statistics. 

DisplayStats(); 
These lines increase the player’s defensive power and experience when- 
ever he finds a shield. The m_playerDefense Statistic is equal to the 
item value you gave the shield when you designed the dungeon. The 
m_curArmor variable determines which shield image to display on the 
screen. 


Add the following lines to the end of the GetTreasure() function: 


// Increase the player's gold. 
pDoc->m_playerGold += value; 


// Add to player's experience. 
UpdateExper (2) ; 


// Display new statistics. 
DisplayStats(); 


These lines increase the amount of gold the player is carrying. They also 
increase the player’s experience and display the new statistics on the 
screen. 


Add the following lines to the OnCreate() function, after the 
m_rightButtonPressed = FALSE line you placed there previously: 


m_nextLevel[0] = 100; 


m_nextLevel[1] = 200; 
m_nextLevel[2] = 400; 
m_nextLevel[3] = 800; 
m_nextLevel[4] = 1500; 
m_nextLevel[5] = 3000; 
m_nextLevel[6] = 6000; 
m_nextLevel[7] = 12000; 
m_nextLevel[8] = 24000; 


m_nextLevel[9] = 50000; 


This code initializes an array that contains the amount of experience 
points the player needs to advance to the next level (player level, not 
dungeon floor). For example, to be awarded level 2, the player must 


385 


386 


Chapter 10—Incorporating Player Statistics 


have 100 experience points. Similarly, to be awarded level 3, the player 
must acquire 200 experience points. 


11. Load the AZTECVW.H file and add the following line to the class’s 
protected Attributes section, after the lines you placed there previously: 


UINT m_nextLevel[1®]; 


This line declares the m_nextLevel[] array as a data member of the 
CAztecView class. 


12. Add the following lines to the class’s protected Implementation section, 
after the lines you placed there previously: 
void DisplayStats() ; 
void UpdateExper(int exp); 
void CheckLevel(); 
These lines declare the new functions as member functions of the 
CAztecView class. 


This completes version 11 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 11 

Before running this version of Aztec Adventure, you must copy a new 
LEVELO1.DUN file into your AZTEC project directory. You’ll find that file 
on this book’s CD-ROM in the CHAP10\AZTEC11 directory. 


When you run the new version of Aztec Adventure, the window shown in 
figure 10.1 appears. As you can see, the game’s main display now shows the 
player’s current statistics. Press your keyboard’s up-arrow key and start mov- 
ing east. As you gather treasure chests, watch your player statistics change to 
reflect your current status in the game. 


Examining the DisplayStats() Function 

As you built version 11 of Aztec Adventure, you saw how the program 
changes the player’s statistics as he interacts with objects in the dungeon. 
When the player’s statistics change, the screen display must be updated, as 
well. This task is handled by the DisplayStats() function. 


DisplayStats() first acquires a DC for the window. It then selects a black 
brush into the DC, by calling the SelectStockObject() function: 


clientDC.SelectStockObject (BLACK_BRUSH) ; 
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You already know that you can create your own brush types whenever you 
want to draw onto a window’s client area. But Windows keeps a few stock 
objects that you can use. These objects don’t need to be created; instead, 

you use them just by selecting them into the device context with the 
SelectStockObject() function, which requires as a single argument a constant 
representing the object you want to select. In this function, that object is 
BLACK_BRUSH. Other stock objects include GRAY_BRUSH, HOLLOW_BRUSH, 
LTGRAY_BRUSH, NULL_BRUSH, BLACK_PEN, WHITE_PEN, NULL_PEN, and many more. 
(Please consult your programming reference for more information.) 


After selecting the black brush, the program draws six rectangles within a for 
loop, erasing the statistics that appeared on the screen previously: 

for (UINT i=@; i<6; ++i) 

clientDC.Rectangle(470, 159+i*20, 502, 175+i*20) ; 

Then, the program declares a string variable to hold the information that will 
be displayed in the player’s statistics area on the screen. To set the proper text 
and text-background colors, the program calls the SetTextColor() and 
SetBkColor() functions: 

clientDC.SetTextColor (RGB(255,0,0)); 

clientDC.SetBkColor(RGB(0,0,9)); 
These functions take as arguments the colors to set. In the preceding case, 
these colors are represented by the RGB values for red and black. 


Fig. 10.1 

Aztec Adventure 
with player 
Statistics. 
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After taking care of the colors, the program uses the wsprintf() function to 
convert the next statistic to an ASCII string: 


wsprintf(s, "%d", pDoc->m_playerLevel) ; 
This string is printed on the screen by the Textout() function: 
clientDC.TextOut(470, 159, s, strlen(s)); 


TextOut()’s four arguments are the X,Y coordinates at which to place the 
string in the window, a pointer to the string to display, and the length of 
the string. All the player’s statistics are displayed in exactly the same way. 


Examining the UpdateExperience() Function 
Adding to the player’s experience is just a matter of calling the 
UpdateExperience() function, which looks like this: 


void CAztecView: :UpdateExper (int exp) 
{ 


pDoc->m_playerExper += pDoc->m_floorNum * exp; 
CheckLevel(); 
} 


As you can see, the function’s single parameter is an integer. This integer, exp, 
represents the value of the experience increase. However, the actual number 
of experience points awarded to the player is relative to which floor he’s ex- 
ploring. The deeper into the dungeon the player goes, the more experience 
he gets for each task he completes. For example, on floor one, if exp is 2, the 
player gets two experience points. But if the player is on floor 2, an exp of 2 
yields four experience points. 


After increasing the player’s experience, UpdateExper() calls CheckLevel() to 
see whether the player deserves a level increase, too. 


Examining the CheckLevel() Function 

Any increase to the player’s experience may bring his experience total up to 
where he’s entitled to an increase in level. For this reason, every increase in 
experience should be followed by a call to the CheckLevel() function. 


CheckLevel() first retrieves the player’s current experience points and the 
number of points he needs for the next level: 


UINT experience = pDoc->m_playerExper; 
UINT experNeeded = m_nextLevel[pDoc->m_playerLevel-1]; 


The level increase is awarded to the player only if his current experience is 
equal to or greater than the experience needed to get to the next level: 


if (experience >= experNeeded) 


Summary 


If the condition is met, the program tells the player of his level increase: 
MessageBox("Your level is increased", "Level", MB_OK); 


The program then increases the player’s level and displays the new player 
Statistics: 


pDoc->m_playerLevel += 1; 
DisplayStats(); 


If you take a close look at the CAztecDoce class, you'll notice that all the variables that 
control a player’s game status—including not only the player’s statistics, but also 
things like his location in the dungeon—are member variables of the class. You could 
easily create game-save and game-restore features by saving and loading the values 
of these variables in the class’s Serialize() function. You’d also need to add Open 
and Save functions to the File menu. 


Summary 


No matter how many player statistics you want to have in your own RPGs, 
you must declare variables to hold them. Then, as your player makes his way 
through the game, you increase (or decrease) the values stored in those vari- 
ables and display the results on the screen. Of course, if your game has doz- 
ens of player statistics to track, you may not have room for them all on the 
main screen. In this case, you should design some other screen display that 
you can pop up whenever the player wants to see how he’s doing. Critical 
statistics such as hit points, however, should always appear on the main 
screen. 


One of the best ways to gain experience points in Aztec Adventure is to fight 
and destroy the many monsters that roam the dark dungeon halls. As you 
might have guessed, that’s the subject of the next chapter. 
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Nothing makes a dungeon quite so creepy as a few well-designed monsters. 
The monsters, however, do a lot more than create atmosphere. As you design 
dungeon floors for Aztec Adventure, you can use monsters to protect valuable 
treasures, to enable the user to build up experience points, and—most impor- 
tant of all—to act as the trigger to get to the next dungeon floor. In fact, in 
Aztec Adventure, the program depends on the final battle in order to know 
when it’s time to load the next floor. 


Adding monsters isn’t easy, however, both from a programming point of 
view and an artistic point of view. First, battling monsters means creating at 
least a simple animation of the monster attacking and being attacked. The 
animation sequence lets the player know what’s going on. Even tougher, 
though, is creating artwork for the monsters. Each creature requires many 
images, and, unless you’re an accomplished artist, you will undoubtedly find 
it difficult to come up with creatures that look realistic enough. 


You'll solve the programming problem in this chapter. Here, you’ll learn how 
to control the battle between the player and the monster, as well as how to 
create the necessary animation. If you want additional artwork, though, 
you'll need to find an artist. If you’re lucky, you have a friend who’s skilled in 
designing computer graphics. If not, you may have to hire an artist for your 
games. You might also want to check out Appendix B, which offers some 
advice on creating game graphics. 
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Creating Aztec Adventure, Version 12 


You can’t, of course, fight invisible monsters (well, not easily, anyway). So 
the first order of business is to display monsters in the dungeon. As you'll 
soon see, this task isn’t much different than displaying treasure chests, some- 
thing you already know how to do. You just need to blit the appropriate 
image to the appropriate location on the screen. 


The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAP11\AZTEC12 directory of this 
book’s CD-ROM. 


1. Load the AZTECDOC.CPP file and find the CAztecDoc class’s construc- 
tor. Comment out the lines that construct CDib objects from the 
LEVELO1A.BMP and LEVELO1B.BMP files. 


You'll be creating a new function that will load the bitmaps needed for 
each floor. 


2. Add the following line to the end of the constructor, after the lines you 
placed there previously: 


LoadFloorDIBs(1); 


This line calls the function that loads the bitmaps needed for a specific 
floor. The bitmaps are first loaded here so that the CAztecView class has 
access to the color tables in order to create an identity palette. This 
function’s single argument is the floor for which the bitmaps should be 
loaded. 


3. In the CAztecDoc class’s destructor, comment out the lines that delete 
m_pPartsADib and m_pPartsBDib. 


You'll be creating a new function that will delete the bitmaps associated 
with a specific floor. 


4. At the end of the destructor, add the following line: 
DeleteFloorDIBs(); 
This line calls the function that deletes the bitmaps for a specific floor. 


5. Add the following lines to the OnNewDocument() function, right after the 
line m_playerAttack = © you placed there previously: 
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// Initialize the game-over flag. 
m_gameOver = FALSE; 


// Initialize the floor-bitmap pointers. 


m_pPartsADib = @ 
m_pPartsBDib = 0; 


m_pMonsterADib = 0; 
m_pMonsterBDib = 0; 
m_pMonsterCDib = Q; 


// Load the bitmaps for floor 1. 
LoadFloorDIBs (1); 


These lines initialize the bitmap pointers, as well as load the bitmaps for 
the first floor at the beginning of each new game. 


6. Add the following line to the DeleteContents() function, right after the 
if statement’s closing brace: 


// Delete the bitmaps associated with the current floor. 
DeleteFloorDIBs(); 


Because DeleteContents() is called before creating a new document 

(in Aztec Adventure’s case, before starting a new game), this call to 
DeleteFloorDIBs() ensures that the currently loaded bitmaps are deleted 
before the program loads new ones. 


7. Add the following functions to the end of the AZTECDOC.CP?P file: 


void CAztecDoc::LoadFloorDIBs(UINT floor) 


{ 


// Convert the floor number to a string. 
char s[5]; 
wsprintf(s, "%d", floor); 


// Create a file-name CString object. 
CString floorFileName("LEVELXXA.BMP") ; 


// Add the floor number to the file name. 
if (floor < 10) 


floorFileName.SetAt(5, '0'); 
floorFileName.SetAt(6, s[Q]); 


} 
else 
{ 
floorFileName.SetAt(5, s[@]); 
floorFileName.SetAt(6, s[1]); 
} 


// Construct a CDib object from the "Parts A" bitmap. 
m_pPartsADib = new CDib(floorFileName) ; 


// Change the file name for the "Parts B" bitmap. 
floorFileName.SetAt(7, 'B'); 
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// Construct a CDib object from the "Parts A" bitmap. 
m_pPartsBDib = new CDib(floorFileName) ; 


// Change the file name for the "Monster A" bitmap. 
floorFileName.SetAt(0, 'M'); 
floorFileName.SetAt(1, '0'); 
floorFileName.SetAt(2, 'N'); 
floorFileName.SetAt(3, 'S'); 
floorFileName.SetAt(4, 'T'); 
floorFileName.SetAt(7, 'A'); 


// Construct a CDib object from the "Monster A" bitmap. 
m_pMonsterADib = new CDib(floorFileName) ; 


// Load the "Monster B" bitmap. 
floorFileName.SetAt(7, 'B'); 
m_pMonsterBDib = new CDib(floorFileName) ; 


// Load the "Monster C" bitmap. 
floorFileName.SetAt(7, 'C'); 
m_pMonsterCDib = new CDib(floorFileName) ; 


// Initialize pointers to the monster image data. 
m_pMonsterABits = m_pMonsterADib->GetDibBitsPtr() ; 
m_pMonsterBBits = m_pMonsterBDib->GetDibBitsPtr() ; 
m_pMonsterCBits = m_pMonsterCDib->GetDibBitsPtr() ; 


i} 


} 


void CAztecDoc: :DeleteFloorDIBs() 
{ 
// Delete the bitmaps associated with the current floor. 
delete m_pPartsADib; 
delete m_pPartsBDib; 
delete m_pMonsterADib; 
delete m_pMonsterBDib; 
delete m_pMonsterCDib; 


// Reinitialize all of the CDib pointers. 
m_pPartsADib = 0; 
m_pPartsBDib = Q; 
m_pMonsterADib = 
m_pMonsterBDib = Q; 
m_pMonsterCDib 


iT 
Ss 


} 


These are the functions that load and delete the bitmaps associated 
with a particular dungeon floor. You'll look at them in detail later in 
this chapter. 


8. Load the AZTECDOC.H file and add the following lines to the 
CAztecDoc class’s public Attributes section, after the lines you placed 
there previously: 


10. 


11. 


12. 
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CDib* m_pMonsterADib; 
CDib* m_pMonsterBDib; 
CDib* m_pMonsterCDib; 
BYTE* m_pMonsterABits; 
BYTE* m_pMonsterBBits; 
BYTE* m_pMonsterCBits; 


These lines declare pointers to the CDib objects and the images those 


objects contain. These pointers are public data members of the 
CAztecDoc class. 


Add the following lines to the CAztecDoc class’s protected Implementa- 
tion section, after the line you placed there previously: 


void LoadFloorDIBs(UINT floor); 
void DeleteFloorDIBs(); 


These lines declare member functions of the CAztecDoc class. 


Load the AZTECVW.CPP file and add the following lines to the 
DrawView() function, at the end of the if statement and right before the 
for statement’s closing brace: 

else if (m_objects[i] == Monster) 

ShowMonster (i); 
These lines call the function that displays a monster in the 3-D dun- 
geon view. 


Add the following lines to the CalcView() function, right after the 
m_objects[i] = item->iType line you placed there previously: 


// Store the item's number. 
m_objNums[i] = item->iNumber; 


These lines store the item’s number in the array m_objNums[]. The 
monster-display functions need this number in order to know which 
monster to display. 


Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :ShowMonster(UINT squareNum) 


// Coordinates for placing monsters in the WinG bitmap. 
int monstercoords[13][6] = 
{ 

0, 0, ©, ©, ©, 2, 

0, ©, ©, 0, 0, 2, 

19, 88, 208, 360, 74, 74, 

155, 88, 208, 360, 74, 74, 

80, 88, 208, 360, 74, 74, 

0, 78, 34, 360, 70, 104, 

169, 78, 0, 360, 70, 104, 
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67, 78, ©, 360, 104, 104, 
O, 52, 120, ©, 60, 180, 
179, 52, ©, 0, 60, 180, 
36, 52, 0, ©, 180, 180, 
o, ©, ©, ©, 0, 0, 

o, ©, ©, 0, ©, @ 

}; 


// Get a pointer to the appropriate monster images. 
CDib* pMonsterDib = GetMonsterDib(m_objNums[squareNum] ) ; 


// Get a pointer to the monster bitmap's 
// BITMAPINFO structure. 
LPBITMAPINFO pBmInfo = 

pMonsterDib ->GetDibInfoPtr() ; 


// Blit the monster image to the WinG bitmap. 
CopyDIBToWinGTrns((BYTE*)m_pWinGDibBits, 
monstercoords[squareNum] [0], 
monstercoords[squareNum][1], 
pMonsterDib, 
monstercoords[squareNum] [2], 
monstercoords[squareNum] [3], 
monstercoords[squareNum] [4], 
monstercoords[squareNum][5], 253); 


} 
CDib* CAztecView: :GetMonsterDib(UINT monsterNum) 
{ 
CDib* pMonsterDib; 
// Choose a monster bitmap based on 
// the monster's item number. 
switch(monsterNum) 
{ 
case @: pMonsterDib = pDoc->m_pMonsterADib; break; 
case 1: pMonsterDib = pDoc->m_pMonsterBDib; break; 
case 2: pMonsterDib = pDoc->m_pMonsterCDib; 
} 
return pMonsterDib; 
} 


These are the functions that display the monsters. You'll look at them 
in detail later in this chapter. 


13. Load the AZTECVW.H file and add the following line to the CAztecView 
class’s protected Attributes section, after the data declarations you 
placed there previously: 


UINT m_objNums[13]; 


This line declares the m_objNums[] array as a data member of the 
CAztecView class. 
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14. Add the following lines to the CAztecView class’s protected Imple- 
mentation section, after the function declarations you placed there 
previously: 

void ShowMonster(UINT squareNum) ; 

CDib* GetMonsterDib(UINT monsterNum) ; 
These lines declare the monster-display functions as member functions 
of the CAztecView class. 


This completes version 12 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 12 

Before running this version of Aztec Adventure, you must copy a new 
LEVELO1.DUN file, as well as the MONSTO1A.BMP, MONSTO1B.BMP, and 
MONSTO1C.BMP files, to your AZTEC project directory. You'll find these files 
on this book’s CD-ROM in the CHAP11\AZTEC12 directory. 


When you run the new version of Aztec Adventure, the window shown in 
figure 11.1 appears. In the distance, you can see a giant snake waiting for 
your approach. Move eastward toward the monster. When you get right in 
front of him, he looks like figure 11.2. If you keep moving eastward, you’ll 
run into the nasty critters shown in figures 11.3 and 11.4. 


: ‘Aztec Adventure . j P : ae GIS fa ha Fig. 11.1 


Version 12 of 
Aztec Adventure. 
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Fig. 11.2 
A giant snake. 


Fig. 11.3 
A disagreeable 
alligator. 


Fig. 11.4 
Not exactly a 
house cat. 
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Examining the LoadFloorDIBs() Function 

Before you can display creatures in the dungeon’s 3-D view, the program 
must load the bitmaps that contain the creatures’ images. This task is 
handled by the LoadFloorD1Bs() function. 


LoadFloorDIBs() first converts the current floor number to a string so that it 
can be used in file-name construction: 


char s[5]; 
wsprintf(s, "xd", floor); 


The program then constructs a CString object for the file name: 
CString floorFileName("LEVELXXA.BMP") ; 


CString is a string-handling class provided by Visual C++. In the preceding 
string, Xx will be replaced by a two-digit number representing the current 
floor. 


After constructing the CString object, the program adds the floor number to 
the file-name string: 


if (floor < 10) 


floorFileName.SetAt(5, '0'); 
floorFileName.SetAt(6, s[®]); 


} 
else 
{ 
floorFileName.SetAt(5, s[@]); 
floorFileName.SetAt(6, s[1]); 
} 


The SetAt() function, which is a member function of the CString class, 
changes the string character at the index given in its first argument to the 
character given as its second argument. 


At this point, the CString object holds a valid file name for the current floor- 
image file. The program uses the file name to construct a CDib object from 
that “Parts A” bitmap: 


m_pPartsADib = new CDib(floorFileName) ; 


The program constructs a CDib object from the “Parts B” bitmap in the same 
way: 

floorFileName.SetAt(7, 'B'); 

m_pPartsBDib = new CDib(floorFileName) ; 
Now, it’s time to load the monster bitmaps. This means changing the file 
name’s first five characters to MONST and changing the seventh character 
to A, giving the file name MONSTO1A.BMP: 
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floorFileName.SetAt(@, 'M'); 
floorFileName.SetAt(1, '0O'); 
floorFileName.SetAt(2, 'N'); 
floorFileName.SetAt(3, 'S'); 
floorFileName.SetAt(4, 'T'); 
floorFileName.SetAt(7, ‘A'); 


That first set of monster images is then used to construct a CDib object: 
m_pMonsterADib = new CDib(floorFileName) ; 

The remaining two monster bitmaps are loaded in a similar way: 
floorFileName.SetAt(7, 'B'); 
m_pMonsterBDib = new CDib(floorFileName) ; 
floorFileName.SetAt(7, 'C'); 


m_pMonsterCDib = new CDib(floorFileName) ; 


Finally, the program initializes the monster-image pointers to the addressees 
of the images contained in the monster CDib objects: 
m_pMonsterABits 


m_pMonsterBBits 
m_pMonsterCBits 


m_pMonsterADib ->GetDibBitsPtr() ; 
m_pMonsterBDib ->GetDibBitsPtr() ; 
m_pMonsterCDib ->GetDibBitsPtr() ; 


uwoueou 


Examining the DeleteFloorDIBs() Function 

In order to use memory as judiciously as possible, the Aztec Adventure pro- 
gram keeps only the bitmaps it currently needs loaded in memory at one 
time. This means that when the player moves to a new dungeon floor, the 
bitmaps representing the previous floor must be deleted and the new ones 
loaded. You already saw how Aztec Adventure loads the bitmaps for a specific 
floor. The program deletes the bitmaps by calling the DeleteFloorDIBs() 
function. 


First, the function deletes each of the five CDib objects associated with the 
five bitmaps used to create a scene for the current level: 


delete m_pPartsADib; 
delete m_pPartsBDib; 
delete m_pMonsterADib; 
delete m_pMonsterBDib; 
delete m_pMonsterCDib; 


Then, the function sets those pointers to 0 so that the program doesn’t have 
a bunch of invalid cDib pointers floating around: 


m_pPartsADib = Q; 
m_pPartsBDib = @; 


m_pMonsterADib = ð; 
m_pMonsterBDib = ð; 
m_pMonsterCDib = 0; 
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Remember that it’s safe to try to perform a delete operation on a null pointer. The 


operation is just ignored. However, if you delete an object without resetting its 
pointer to null, and then accidentally try to delete the object again, your program 
will crash. 


Examining the ShowMonster() Function 
You’ve already seen how to display objects in the dungeon’s 3-D view. The 
ShowMonster() function works similarly. 


Like the other object-display functions (ShowTreasure(), for example), 
ShowMonster() uses an array of coordinates for determining where a monster 
will appear in the 3-D view: 


int monstercoords[13][6] = 


{ 
0, ©, ©, O, 0, O, 
0, ©, 0, O, 0, 2, 
19, 88, 208, 360, 74, 74, 
155, 88, 208, 360, 74, 74, 
80, 88, 208, 360, 74, 74, 
O, 78, 34, 360, 70, 104, 
169, 78, ©, 360, 70, 104, 
67, 78, 0, 360, 104, 104, 
O, 52, 120, ©, 60, 180, 
179, 52, ©, ©, 60, 180, 
36, 52, 0, ©, 180, 180, 
o, ©, 0, O, 0, 2, 
0, 0, ©, ©, 0, © 

}; 


The main difference with ShowMonster() is that it must be able to display 
three different types of monsters for each level. If you recall, the numbers 
of the items in the current view get stored in the m_objNums[] array. 
ShowMonster() uses the numbers stored in this array to get a pointer to 
the CDib object containing the correct monster images: 


CDib* pMonsterDib = GetMonsterDib(m_objNums[squareNum] ) ; 


You'll look at the GetMonsterDib() function a little later. For now, just know 
that it returns a pointer to the CDib object containing the images for the 
monster whose number is stored in m_objNums[] for the current square. 


Once ShowMonster() has a pointer to the monster’s CDib object, it can get a 
pointer to the bitmap’s BITMAPINFO structure: 
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LPBITMAPINFO pBmInfo = 
pMonsterDib ->GetDibInfoPtr() ; 


Then, because the creature’s image contains transparent pixels, the program 
blits the image to the WinG bitmap by calling the CopyDIBToWinGTrns() func- 
tion, using the coordinates stored in the monstercoords[] array: 
CopyDIBToWinGTrns ( (BYTE*)m_pWinGDibBits, 

monstercoords[squareNum][®], 

monstercoords[squareNum][1], 

pMonsterDib, 

monstercoords[squareNum] [2], 

monstercoords[squareNum] [3], 


monstercoords[ squareNum] [4], 
monstercoords[squareNum][5], 253) ; 


Examining the GetMonsterDib() Function 

Because Aztec Adventure must be able to display three different types of mon- 
sters on each level, it needs a function that will return a pointer to the appro- 
priate images. That function is GetMonsterDib(). 


The function’s single parameter is the number of the monster for which the 
calling function needs the images. That number, stored in monsterNum, is used 
to control a switch statement, which retrieves a pointer to the appropriate 
CDib object: 


switch(monsterNum) 

{ 
case @: pMonsterDib 
case 1: pMonsterDib 
case 2: pMonsterDib 


pDoc->m_pMonsterADib; break; 
pDoc->m_pMonsterBDib; break; 
pDoc ->m_pMonsterCDib; 


} 
Then, ShowMonster() returns the pointer to the calling function: 


return pMonsterDib; 
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Now that you have monsters infesting your dungeon, you’d probably like to 
do something more than just stroll past them. Monsters are for fighting, after 
all! In this section, you add the code necessary to battle and destroy mon- 
sters. Of course, there’s always the chance that they'll destroy you first! 


is step in the creation of the 
EC13 directory of this book’s 


1. 
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Load the AZTECVW.CPP file and add the following lines to the 
MoveForward() function, at the end of the if statement: 


else if (pItem->iType == Monster) 


{ 
pItem->iType = Empty; 
m_fighting = TRUE; 
m_monsterNum = pItem->iNumber; 
m_monsterHP = pItem->iValue; 
FightMonster() ; 
return FALSE; 

} 


These lines trigger the fighting sequence when the player tries to 
move onto a square containing a monster. The program first sets the 
monster’s square to Empty, and then sets the m_fighting flag to TRUE, 
records the monster’s number and value, and calls the FightMonster () 
function, which actually initiates the fighting sequence. 


Find the OnLButtonDown() function and comment out the if statement 
at the very top of the function. Replace the statement with the 
following: 

// If the player is fighting a monster or 

// the game is over, return immediately. 

if (m_fighting |; m_gameOver) 

return; 

These lines prevent the player from doing anything while a fight is 
going on or when the game is over. 


Find the OnKeyDown() function and comment out the if statement at 
the top of the function. Replace the statement with the following: 

// If the player is fighting a monster or 

// the game is over, return immediately. 

if (m_fighting |; m_gameOver) 

return; 

These lines also prevent the player from doing anything while a fight is 
going on or when the game is over. 


Add the following lines to the end of the InitNewGame() function: 


// Initialize the fighting flag. 
m_fighting = FALSE; 


The preceding code ensures that the m_fighting flag is set to FALSE at 
the beginning of every game. 


Add the following lines to the OnCreate() function, right after the 
m_nextLevel[9] = 50000 line you placed there previously: 
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// Seed the random-number generator. 

srand( (unsigned) time(Q) ) ; 
The preceding code gives the random-number generator a different 
starting value each time the ‘Aztec Adventure program is run. Without 
this function call, the sequence of “random” numbers would be the 
same every time. 


6. Use ClassWizard to add the OnTimer() function to the CAztecView class, 
as shown in figure 11.5. 


Fig. 11.5 
Adding the 
OnTimer() 
function. 


ON_WM_LBUTTOND: 
ON_WM_LBUTTONU: 


7. Add the following lines to the OnTimer() function, right after the 
// TODO: Add your message handler code here and/or call default 
comment: 


// Check whether the player is still alive. 
if (pDoc->m_playerHP <= 0) 


{ 
// If the player is dead, turn off the timer. 
KillTimer (1) ; 
return; 

} 


// Define a static variable to hold the 
// number of the last monster image displayed. 
static UINT lastNum = 3; 


// Redraw the 3-D view in the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 


// Get a random number for the next animation frame. 
UINT rndNum; 
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do 

rndNum = rand() % 4; 
while (rndNum == lastNum) ; 
lastNum = rndNum; 


// Perform the next fight action. 
DoNextMonsterFrame (rndNum) ; 


The OnTimer() function, which you'll look at in detail later in this chap- 
ter, controls the animation during a fight. 


8. Add the following line to the end of the OnDestroy() function: 
KillTimer (1); 


This line ensures that the Windows timer is always stopped when the 
program ends. 


9. Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :FightMonster () 


{ 
// Get a pointer to the appropriate 


// set of monster images. 
CDib* pMonsterDib = GetMonsterDib(m_monsterNum) ; 


// Redraw the 3-D view in the WinG bitmap. 
CalcView(FALSE) ; 
DrawView(); 


// Blit the monster-hit image to the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 

36, 52, pMonsterDib, 

@, 180, 180, 180, 253); 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Display the WinG bitmap in the window. 

SelectPalette(clientDC.m_hDC, m_hPalette, FALSE) ; 

RealizePalette(clientDC.m_hDC) ; 

WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, @, 0); 


// Start a Windows timer to time the animation. 
SetTimer(1, 1000, 0); 
} 


void CAztecView: :DoNextMonsterFrame(UINT num) 


{ 
// Get a pointer to the appropriate monster images. 


CDib* pMonsterDib = GetMonsterDib(m_monsterNum) ; 
if (num == 0) 


// Draw the monster-attacking image 
// on the WinG bitmap. 
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CopyDIBToWinGTrns((BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
360, ©, 180, 180, 253); 


// Subtract damage from the player's hit points. 

int damage = (m_monsterNum+1) * pDoc->m_floorNum - 
pDoc ->m_playerDefense; 

if (damage < 0) damage = Q; 

pDoc->m_playerHP -= damage; 


else if (num == 1) 


// Draw the monster-waiting image #1 
// on the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
©, ©, 180, 180, 253); 


else if (num == 2) 


// Draw the monster-waiting image #2 
// on the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
180, ©, 180, 180, 253); 


else if (num == 3) 
{ 
// Draw the monster-hit image on the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
©, 180, 180, 180, 253); 


// Deduct damage from the monster's hit points. 
“m_monsterHP -= 
pDoc->m_playerLevel + pDoc->m_playerAttack; 
} 


// Get a DC for the window. 
CClientDC clientDC(this) ; 4 


// Display the completed animation frame. 

SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 

RealizePalette(clientDC.m_hDC) ; 

WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, @, @); 


// Show the player's statistics. 
DisplayStats(); 


// If the monster is out of hit 
// points he's dead (hurray!). 
if (m_monsterHP <= Q) 
KillMonster (&clientDC) ; 
} 


void CAztecView: :KillMonster(CClientDC* pClientDC) 
{ 
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// Get a pointer to the appropriate monster images. 
CDib* pMonsterDib = GetMonsterDib(m_monsterNum) ; 


// Start loop for a four-frame animation. 
for (UINT i=; i<4; ++i) 


{ 
// Redraw the 3-D scene in the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 
// If it's not the last frame... 
if (i < 3) 
// Blit the next monster animation 
// frame to the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
i*180, 180, 180, 180, 253); 
// Display the next animation frame in the window. 
WinGBitBlt(pClientDC->m_hDC, 51, 51, 240, 240, 
m_hWinGDC, 0, @); 
} 


// Turn off the timer and reset the fighting flag. 
KillTimer (1); 
m_fighting = FALSE; 


// Give the player experience points. 
pDoc->m_playerExper += 
(m_monsterNum + 1 + pDoc->m_floorNum) * 3; 


// Display the player's new statistics and check 
// whether the player has earned the next level. 
DisplayStats(); 
CheckLevel(); 

} 


You'll examine these functions in detail later in this chapter. 


10. Load the AZTECVW.H file and add the following lines to the CAztecView 
class’s protected Attributes section: 
BOOL m_fighting; 
UINT m_monsterNum; 
int m_monsterHP; 
These lines declare new data members for the CAztecView class. 
11. Add the following lines to the CAztecView class’s protected Implementa- 
tion section: 
void FightMonster(); 
void DoNextMonsterFrame(UINT num) ; 
void KillMonster(CClientDC* pClientDC) ; 


These lines declare new member functions for the CAztecView class. 
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Fig. 11.6 
You attack the 
snake. 


Fig. 11.7 
The snake fights 
back. 


This completes version 13 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 13 

Before running this version of Aztec Adventure, you must copy a new 
LEVELO1.DUN file to your AZTEC project directory. You’ll find that file on 
this book’s CD-ROM in the CHAP11\AZTEC13 directory. 


When you run the new version of Aztec Adventure, the main window ap- 
pears. In the distance, you can see a giant snake waiting to take a bite out of 
unwary adventurers. Move eastward toward the snake. When you try to move 
onto its square, the fight begins. As figure 11.6 shows, you get the first swing. 
But the creature won’t let you get away with your attack. He’ll fight back (see 
fig. 11.7). Eventually, though, you'll get the best of the snake, and he’ll dis- 
solve from view, leaving you free to move forward through the dungeon. 
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Examining the FightMonster() Function 

Fighting monsters in a dungeon may be fun from a player’s point of view, 
but from a programming view, it’s serious business. Here’s how it all works. 
When the player tries to step into the a square containing a monster, the 
FightMonster() function starts the fight. 


FightMonster() first gets a pointer to the CDib object holding the images for 
the current monster: 


CDib* pMonsterDib = GetMonsterDib(m_monsterNum) ; 


It then displays the first frame of the fight sequence, which is the player strik- 
ing the creature: 
CalcView(FALSE) ; 
DrawView() ; 
CopyDIBToWinGTrns((BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
O, 180, 180, 180, 253); 
CClientDC clientDC(this) ; 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 
WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, 0, 0); 
The first frame of the fight is displayed in FightMonster(), rather than in 
OnTimer(), where the rest of the animation takes place. This is because you 
want the first image to appear immediately, rather than wait for Windows to 


call the timer function. 


After displaying the first frame of the fight sequence, FightMonster() starts a 
Windows timer: 


SetTimer(1, 1000, 0); 


The preceding call tells Windows to send timer events to Aztec Adventure 
every 1000 milliseconds. (You learned about Windows timers in Chapter 4, 
“Programming with WinG.”) These events will be handled by the OnTimer() 
function. In fact, OnTimer() handles the rest of the animation from this point 
on. By setting a timer to 1000 milliseconds, the program gets a timer message 
every 1/10 of a second, which means the maximum frame rate for the anima- 
tion is 10 frames per second. If the program can’t keep up with this rate, 
Windows automatically throws away the unused timer events. 


Examining the OnTimer() Function 

After setting the Windows timer in FightMonster(), the program receives 
WM_TIMER messages from Windows every 1/10 of a second. MFC routes these 
events to the CAztecView class’s OnTimer() function. 


409 


410 Chapter 11—Battling Dungeon Monsters 


OnTimer() first checks the player’s hit points. If the player’s hit points are zero 
or less, the game is over, so the program turns off the timer and returns from 
the function: 


if (pDoc->m_playerHP <= @) 


{ 
// If the player is dead, turn off the timer. 
KillTimer (1); 
return; 

} 


The first time OnTimer() gets called, the program initializes a static variable to 
hold the number of the last image the function displayed: 


static UINT lastNum = 3; 


The program then redraws the 3-D view in the WinG bitmap. This view does 
not include the monster because the MoveForward() function already set the 
monster’s square to Empty: 

CalcView(FALSE) ; 

DrawView(); 
Next, the program gets a new random number, which the function will use to 
determine which animation frame to display next: 

UINT rndNum; 

do 

rndNum = rand() % 4; 

while (rndNum == lastNum) ; 

lastNum = rndNum; 
As you can see by the preceding code, the program keeps selecting random 
numbers until it gets one different from the last one used (stored in lastNum). 
This prevents the program from displaying the same image twice in a row. 


Finally, OnTimer() calls DoNextMonsterFrame() to perform the action selected 
by the random number: 


DoNextMonsterFrame(rndNum) ; 


Examining the DoNextMonsterFrame() Function 
Whereas the OnTimer() function controls the animation, the function 
DoNextMonsterFrame() actually performs it. 


DoNextMonsterFrame()’s single parameter, num, is the number of the animation 
frame to display. If num is O, the function must display the monster attacking 
the player: 


if (num == Q) 


{ 
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CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
360, @, 180, 180, 253); 


int damage = (m_monsterNum+1) * pDoc->m_floorNum - 
pDoc ->m_playerDefense; 
if (damage < 0) damage = 0; 
pDoc->m_playerHP -= damage; 
} 


Here, the program first displays the image of the monster attacking and then 
deducts damage from the player’s hit points. Because a large defense value 
could cause the calculation of damage to come out negative, the variable 
damage is checked after the calculation and set to 0 if it’s negative. In the last 
line in the preceding code, the damage is subtracted from the player’s hit 
points. If damage was allowed to become negative, the player could actually 
gain hit points when the monster attacks, a situation that makes no sense. 
(Remember, subtracting a negative number is the same as adding a positive 
one.) 


If num is 1 or 2, the program must display one of the two “waiting” monster 
images: 
else if (num == 1) 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
0, ©, 180, 180, 253); 
else if (num == 2) 
CopyDIBToWinGTrns ( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
180, ©, 180, 180, 253); 


These images make the monster appear to twitch its tail, or perform some 
other movement, between attacks. 


If num is 3, the program must display the monster being struck by the player: 
else if (num == 3) 


CopyDIBToWinGTrns ( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
©, 180, 180, 180, 253); 
m_monsterHP -= 
pDoc->m_playerLevel + pDoc->m_playerAttack; 
} 


Here, after copying the image of the wounded creature to the WinG bitmap, 
the program deducts damage from the creature’s hit points. The amount of 


damage sustained by the creature depends on the level the player has at- 
tained and the weapon he’s using. 
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After blitting the chosen creature image to the WinG bitmap, the program 
must display the completed animation frame: 

CClientDC clientDC(this) ; 

SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 

RealizePalette(clientDC.m_hDC) ; 

WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 

m_hWinGDC, 0, Q); 

Because the player may have lost some hit points, the program must also 
display the player’s statistics: 


DisplayStats(); 


Finally, if the monster has lost all its hit points, DoNextMonsterFrame() calls 
the KillMonster() function to end the unfortunate critter’s life: 


if (m_monsterHP <= Q) 
KillMonster (&clientDC) ; 


Examining the KillMonster() Function 

Luckily for the player, most dungeon brawls will leave the monster deader 
than dungeon dust. When the player defeats a monster, the program execu- 
tion jumps to the KillMonster() function. 


KillMonster()’s single parameter is a pointer to a CClientDC object, which is 
the DC DoNextMonsterFrame() was using to display the monster images. 
KillMonster() first gets a pointer to the CDib object containing the current 
monster’s images: 


CDib* pMonsterDib = GetMonsterDib(m_monsterNum) ; 


The program then performs a four-frame animation to display the dissolving 
creature: 


for (UINT i=0; i<4; ++i) 


{ 
CalcView(FALSE) ; 
DrawView() ; 
if (i < 3) 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
i*180, 180, 180, 180, 253); 
WinGBitBlt(pClientDC->m_hDC, 51, 51, 240, 240, 
m_hWinGDC, ©, @); 
} 


You saw this animation technique used to open doors in Chapter 9, “Placing 
Objects in the Dungeon.” 


After the animation is done, the program turns off the timer and sets the 
m_fighting flag to FALSE: 
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KillTimer (1); 
m_fighting = FALSE; 
Finally, the program awards the player with experience points, as well as 
displays the player’s new statistics and checks whether the player has earned 
the next warrior level: 
pDoc->m_playerExper += 
(m_monsterNum + 1 + pDoc->m_floorNum) * 3; 


DisplayStats(); 
CheckLevel(); 


Creating Aztec Adventure, Version 14 


You’ve now declared war on the creatures that roam your dungeon corridors. 
However, although you can destroy them, there’s not a heck of a lot they can 
do about you. Sure, they can take away your hit points, but when your hit 
points reach zero, nothing happens, which is hardly sportsmanlike. 


In this section, you’ll add the code needed to end the game when the player’s 
hit points reach zero, as well as allow the player to enter the next dungeon 
floor if he beats the final monster on a floor. You'll also enable the player to 
use elixir to increase his hit points. Finally, because this is the last section 
that deals with the game’s graphics, you’ll add the functions needed to re- 
spond to WM_QUERYNEWPALETTE and WM_PALETTECHANGED messages. 


The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAP11\AZTEC14 directory of this 
book’s CD-ROM. 


1. Load the AZTECDOC.CPP file and add the following function to the 
end of the file: 


BOOL CAztecDoc::StartNextFloor() 
{ 
// Reinitialize game variables. 
m_playerX = 1; 
m_playery 13 
m_faceDir East; 
m_potionCount = 0; 


nowt 


for (UINT i=@; i<6; ++i) 
{ 
m_keys[i] = FALSE; 
m_potionValues[i] = Q; 
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// Increment the floor number. 
++m_floorNum; 


// Convert the floor number to a string. 
char s[5]; 
wsprintf(s, "%d", m_floorNum) ; 


// Construct the file name for the new floor-data file. 
if (m_floorNum < 10) 


{ 
m_pLevelFileName->SetAt(5, '0'); 
m_pLevelFileName->SetAt(6, s[@]); 
} 
else 
{ 
m_pLevelFileName ->SetAt(5, s[Q]); 
m_pLevelFileName->SetAt(6, s[1]); 
} 


// Delete the contents of the old m_Dungeon array. 
DeleteContents(); 


// Load the new data into the m_Dungeon array. 
LoadLevel(); 


// If the new level data was found, load 
// the associated bitmaps. 
if (!m_gameOver) 


{ 
} 


LoadFloorDIBs(m_floorNum) ; 


return m_gameOver; 


} 


This function prepares the program’s data to begin a new dungeon 
floor. You’ll look at this function in detail later in this chapter. 


Find the OnNewDocument() function and add the following lines after the 
LoadFloorDIBs(1) line you placed there previously: 


// Set the file name for floor 1. 
*m_pLevelFileName = "“LEVEL@1.DUN"; 


The preceding code sets the floor-data’s file name to LEVELO1.DUN at 
the beginning of a new game. 


Load the AZTECDOC.H file and add the following line to the CAztecDoc 
class’s public Operations section, right after the public keyword: 


BOOL StartNextFloor(); 


This line declares StartNextFloor() as a public member function of the 
CAztecDoc class. This function is public so that it can be called by the 
CAztecView Class. 


7. 
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Load the AZTECVW.CPP file and add the following lines to the 
OnTimer() function, in the first if statement and right after the 
KillTimer(1) line you placed there previously: 

// End the game. 

PlayerDead(); 
The preceding code calls the function that kills off the player’s charac- 
ter when he’s defeated by a monster. 


Add the following lines to the very end of the KillMonster() function, 
after the CheckLevel() function call you placed there previously: 


// If the player has defeated the boss monster, 

// move the player to the next floor. 

if ((pDoc->m_playerX == 29) && (pDoc->m_playerY == 1)) 
StartNextFloor(); 


These lines move the player to the next dungeon floor when he defeats 
the monster in the last room of the current dungeon floor. 


Add the following lines to the end of the second if statement in the 
OnLButtonDown() function, right after the HandleRightButton(clientDC, 
pBmInfo) line you placed there previously: 


// Clicked on the potions? 
else if ((point.x > 312) && (point.x < 502) && 
(point.y >351) && (point.y < 384) && 
(pDoc->m_potionCount > @)) 
HandlePotions() ; 


These lines check whether the player clicked on the elixir display. If he 
did, and he has at least one elixir bottle in his inventory, the program 
calls the HandlePotions() function to let the player use the elixir. 


Add the following functions to the end of the AZTECVW.CPP file: 


void CAztecView: :StartNextFloor() 
{ 
// Tell the player he's completed the floor. 
MessageBox( "You finished the floor.", 
"Level", MB_OK); 


// Tell the document to load bitmaps 

// for the next floor. If pDoc->StartNextFloor() 
// returns TRUE, there are no other bitmaps and 
// the game is over. 

m_gameOver = pDoc->StartNextFloor(); 


// If the game isn't over, set up the next floor. 
if (!m_gameOver) 
{ 
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// Delete the old WinG DC, bitmap, and identity 
// palette. 
DeleteWinGStuf f () ; 


// Create the new WinG DC, 
// bitmap, and identity palette. 
SetUpWinGStuf f (); 


// Initialize variables. 
InitNewGame(); 


// Get a pointer to the "Parts A" bitmap. 
m_pPartsDib = pDoc->m_pPartsADib; 


// Redraw the 3-D view in the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 


// Force the window to display the new screen. 
Invalidate (FALSE); 
} 
else 
// If there's no other floor, the player has won. 
PlayerWins(); 
} 


void CAztecView: :HandlePotions() 
{ 
// Ask whether the player wants to use an elixir. 
UINT result = MessageBox("Do you want to use Elixir?", 
"Elixir", MB_ICONQUESTION {| MB_YESNO) ; 


// If the player answers Yes... 
if (result == IDYES) 
{ 
// Take away one elixir and 
// add to the player's hit points. 
pDoc->m_potionCount -= 1; 
pDoc->m_playerHP += 
pDoc ->m_potionValues[pDoc->m_potionCount] ; 
if (pDoc->m_playerHP > 100) 
pDoc->m_playerHP = 100; 


// Update the statistics and elixirs on the 
// display. 
DisplayStats(); 
DisplayPotions(); 
} 
void CAztecView: :PlayerDead() 


// Set game-over flag. 
m_gameOver = TRUE; 


// Blit the player-dead image to the WinG bitmap. 
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CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
©, ©, pDoc->m_pSundryDib, 400, ©, 240, 240); 


// Force the window to repaint itself. 
Invalidate (FALSE) ; 


// Display the player's final score. 
ShowScore(); 
} 


void CAztecView: :PlayerWins() 


{ 
// Set the game-over flag. 


m_gameOver = TRUE; 


// Blit the player-wins image to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
@, ©, pDoc->m_pSundryDib, 400, 240, 240, 240); 


// For the window to repaint. 
Invalidate (FALSE); 


// Display the player's final score. 
ShowScore(); 
} 


void CAztecView: :ShowScore() 


{ 
// Calculate the player's score. 


UINT score = (pDoc->m_playerLevel * 1000) + 
pDoc->m_playerExper + pDoc->m_playerGold; 


// Build the score display string. 
char s[25]; 
wsprintf(s, "Your Score: %d", score); 


// Show the score display string. 
MessageBox(s, "Score", MB_OK); 
} 


You'll look at these functions later in the chapter. 


8. Load the AZTECVW.H file and add the following lines to the CAztecView 
class’s protected Implementation section: 
void StartNextFloor() ; 
void HandlePotions() ; 
void PlayerDead(); 
void PlayerWins(); 
void ShowScore() ; 
These lines declare the new functions as member functions of the 


CAztecView Class. 


9. Use ClassWizard to add the OnPaletteChanged() function to the 
CMainFrame class, as shown in figure 11.8. 
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Fig. 11.8 

Adding the 
OnPaletteChanged() 
function. 


10. 


11. 


12. 
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Add the following code to the OnPaletteChanged() function, after the 
// TODO: Add your message handler code here comment: 


// Get a pointer to the view window. 
CView* pView = GetActiveView() ; 


// If it isn't the view window changing 
// the palette, redraw the view window with 
// the newly mapped palette. 
if (pFocusWnd != pView) 
pView->Invalidate(FALSE) ; 
These lines force the application’s main window to repaint whenever 
another application changes the palette. You learned this technique in 


Chapter 2, “Manipulating Device-Independent Bitmaps.” 


Use ClassWizard to add the OnQueryNewPalette() function to the 
CMainFrame class, as shown in figure 11.9. 


Add the following code to the OnQueryNewPalette() function, after the 
// TODO: Add your message handler code here and/or call default 
comment: 


// Get a pointer to the view window. 
CView* pView = GetActiveView(); 


// Redraw the view window with its own colors. 
pView->Invalidate(); 


These lines force the application’s main window to repaint whenever 
the application becomes the active window. You learned this technique 
in Chapter 2, “Manipulating Device-Independent Bitmaps.” 


Creating Aztec Adventure, Version 14 419 


This completes version 14 of Aztec Adventure. To compile the program, select 
the Project menu’s Build command. Visual C++ then compiles and links the 
application. 


Running Aztec Adventure, Version 14 

Before running this version of Aztec Adventure, you must copy a new 
LEVELO1.DUN file to your AZTEC project directory. You also must add 
the LEVELO2.DUN, LEVELO2A.BMP, LEVELO2B.BMP, MONSTO2A.BMP, 
MONSTO2B.BMP, and MONST02C.BMP files to your directory. You'll find 
these files on this book’s CD-ROM in the CHAP11\AZTEC14 directory. 


When you run the new version of Aztec Adventure, the main window ap- 
pears. Walk eastward and fight the alligator you'll find there. After defeating 
the alligator, continue east until you find an elixir. After picking up the elixir, 
use it by clicking on it in your inventory. When you do, your hit points 

go up. 


Now, keep going east until you find a key. Pick up the key and continue east 
until you get to a set of doors. This is the last room in the dungeon—the one 
that contains the boss creature. Open the door and fight the creature. When 
you win the battle, you’ll move on to the next dungeon floor, as shown in 
figure 11.10. 


Now, turn to the south and keep walking until you stumble upon another 
creature. Pick a fight, and you'll soon discover that this guy isn’t as wimpy as 
the first one you fought. In fact, after a long battle, your warrior will die, and 
you'll see the screen shown in figure 11.11. 


Fig. 11.9 
Adding the 
OnQueryNew- 
Palette() function. 


420 Chapter 11—Battling Dungeon Monsters 


Fig. 11.10 
The second 
dungeon floor. 


Fig. 11.11 
The warrior dies. 


After mourning your warrior’s demise, restart the game and follow the same 
path you did before. But this time when you get to floor two, go east instead 
of south. At the end of the corridor, you'll find a key for the last room. Pick 
up the key, open the door, and fight the monster. When you beat the mon- 
ster, you'll see a screen like figure 11.12. This is the game-over screen you see 
when you win the game. (The Fire Snake is the last creature on floor three, 
not the creature you just defeated.) 
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Aztec Adventure 


Examining the HandlePotions() Function 

As the player explores the dungeon and battles the creatures that block his 
way, he’ll lose more and more hit points. If the player doesn’t have a way to 
increase his hit points, he’ll quickly lose the game. That’s where the elixir 
bottles come in. When the user has elixir bottles, they appear in his inven- 
tory. To use one, he just clicks it with his mouse, and the program calls the 
HandlePotions() function. 


HandlePotions() first asks the user whether he wants to use the elixir: 


UINT result = MessageBox("Do you want to use Elixir?", 
"Elixir", MB_ICONQUESTION ; MB_YESNO) ; 
If the user clicks the message box’s Yes button, result will be equal to the 
constant IDYES. In this case, the program subtracts an elixir bottle from the 
player’s inventory: 


pDoc->m_potionCount -= 1; 


Then, the program increases the player’s hit points by the value that was 
stored in the m_potionValues[] array for that potion: 
pDoc->m_playerHP += 
pDoc->m_potionValues|[ pDoc ->m_potionCount] ; 


if (pDoc->m_playerHP > 100) 
pDoc->m_playerHP = 100; 


Notice that the player’s hit points are not allowed to exceed 100. 


Fig. 11.12 
The warrior 
completes his 
quest. 
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After giving the player his hit-point boost, the program must display the 
player’s new statistics. It must also display the remaining elixir bottles: 


DisplayStats(); 
DisplayPotions(); 


Examining the PlayerWins() Function 
When the player defeats the last monster on the last floor, he wins the game. 
The PlayerWins() function takes care of ending the game in this case. 


First, PlayerWins() sets the m_gameOver flag to TRUE: 
m_gameOver = TRUE; 
As you may remember, the m_gameOver flag is used in functions such as 


OnLButtonDown() and OnKeyDown() to prevent the user from using the game’s 
controls when the game is over. 


Next, PlayerWins() blits the appropriate game-over image (the one that says 
the player beat the Fire Snake) to the WinG bitmap: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
©, ©, pDoc->m_pSundryDib, 400, 240, 240, 240); 
Then, to display the WinG bitmap on the screen, the program calls 
Invalidate() to force the window to repaint: 


Invalidate(FALSE) ; 


And, finally, the program calls the ShowScore() function to display the 
player’s score: 


ShowScore(); 


The PlayerDead() function, which is called when the player runs out of hit 
points and loses the game, works almost exactly like PlayerWins(). It just 
displays a different game-over image. 


Examining the ShowScore() Function 

So that players can compare their performance with other players, Aztec Ad- 
venture calculates a score at the end of the game. This score is based on the 
level the player attained, how many experience points he gathered, and how 
much gold he discovered. The final score is calculated and displayed by the 
DisplayScore() function. 


This function first calculates the score and stores it in the score local variable: 


UINT score = (pDoc->m_playerLevel * 1000) + 
pDoc->m_playerExper + pDoc->m_playerGold; 
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It then calls wpsrintf() to convert the integer score value to ASCII characters: 


char s[25]; 
wsprintf(s, "Your Score: %d", score); 


This score string is finally displayed in a message box: 


MessageBox(s, "Score", MB_ OK); 


Exploring CAztecView’s StartNextFloor() Function 

When the player defeats the boss creature in the last room of a dungeon floor 
(always the room in the dungeon’s upper right corner), it’s time to start the 
next floor. Starting a new dungeon floor is a fairly complicated process, re- 
quiring that new bitmaps be loaded and game data be reinitialized. This pro- 
cess begins in the CAztecView class’s StartNextFloor() function. 


StartNextFloor() first displays a message box, telling the player that he has 
finished the current floor: 
MessageBox( "You finished the floor.", 
"Level", MB_OK); 
The program then calls the CAztecDoc class’s version of StartNextFloor(), 


which is responsible for loading the bitmaps associated with the next floor, 
as well as initializing game variables stored in the document object: 


m_gameOver = pDoc->StartNextFloor(); 


You'll look at the CAztecDoc class’s StartNextFloor() soon. For now, be aware 
that that function returns a Boolean value indicating whether the game is 
over. This Boolean value is TRUE when the document class has used up all the 
data files with the DUN extension (the data files you create for each floor 
with Dungeon Designer). 


If the game isn’t yet over, the program calls DeleteWinGstuff() to delete the 
current WinG DC, bitmap, and identity palette: 


DeleteWinGStuff () ; 


A call to SetUpWinGstuff() gets WinG ready for the next floor, creating an 
identity palette based on the colors used for the new floor: 


SetUpWinGStuf fF () ; 


You created the DeleteWinGstuff() and SetUpWinGSstuff() functions in Chap- 
ter 7, “Aztec Adventure and WinG.” 


The program then calls InitNewGame() to reinitialize game variables in the 
CAztecView class and sets the m_pPartsDib pointer to the address of the new 
“Parts A” CDib object: 
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InitNewGame () ; 
m_pPartsDib = pDoc->m_pPartsADib; 


Finally, the program displays the new 3-D view created by the new floor data 
and bitmaps: 

CalcView(FALSE) ; 

DrawView() ; 

Invalidate(FALSE) ; 
If the call to the CAztecDoc class’s StartNextFloor() function returned TRUE, 
meaning the game is over, the player has made it to the end of the game. In 
this case, CAztecView's StartNextFloor() function skips all the preceding 
steps and only calls the PlayerWins() function. 


Examining CAztecDoc’'s StartNextFloor() Function 

The view object’s StartNextFloor() function reinitializes the data that the 
view needs to begin a new floor. However, the document object also contains 
a great deal of data that must be initialized for each floor. This data includes 
game variables, as well as the bitmaps that represent the dungeon and the 
dungeon’s monsters. The CAztecDoc class’s StartNextFloor() function handles 
these tasks for the document class. 


This function first initializes the variables that determine the player’s location 
and facing direction in the dungeon: 
m_playerx 


m_playery 
m_faceDir 


1; 
1; 
East; 


The program also removes all leftover elixir bottles and keys from the player’s 
inventory: 


m_potionCount = 0; 


for (UINT i=0; i<6; ++i) 
{ 
m_keys[i] = FALSE; 
m_potionValues[i] = 0; 
} 


Next, the program increments the floor number and converts the result to an 
ASCII string: 
++m_floorNum; 


char s[5]; 
wsprintf(s, "%d", m_floorNum) ; 
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The program then uses this ASCII string to build a new file name for the new 
floor’s data: 


if (m_floorNum < 10) 


{ 
m_pLevelFileName->SetAt(5, 'O'); 
m_pLevelFileName->SetAt(6, s[@]); 
} 
else 
{ 
m_pLevelFileName->SetAt(5, s[Q]); 
m_pLevelFileName->SetAt(6, s[1]); 
} 


A call to DeleteContents() destroys the contents of the old m_Dungeon array 
and the LoadLevel() function reinitializes the array with the items in the new 
dungeon floor: 


DeleteContents(); 
LoadLevel(); 


The call to LoadLevel() sets the data member m_gameOver to TRUE if there is 
no new floor to load and to FALSE if there is another floor. StartNextFloor() 
checks m_gameOver to see whether it should load new bitmaps for the floor: 


if (!m_gameOver) 


LoadFloorDIBs(m_floorNum) ; 
} 


Obviously, if there’s no next floor, there are no bitmaps to load. 


Finally, the function returns the m_gameOver flag to the calling function: 


return m_gameOver; 


| said earlier in this chapter that you can’t fight an invisible monster. But, as two of 
my kids, Justin and Stephen, pointed out, you actually can fight invisible monsters in 
Aztec Adventure. All you have to do is erase the monster’s “waiting” images with the 
transparent color, leaving only the monster-attacking, wounded-monster, and dis- 
solving-monster images in the bitmap file. Then, you can see the monster only when 
you bump into it (thus accidentally initiating a fight) and when the monster attacks 
you. In the CHAP11 directory of this book’s CD-ROM is a sample graphics file for an 
invisible monster. The name of the file is INVMONST.BMP. 
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Summary 


Once you decide to add monsters to your dungeon (and whoever heard of a 
dungeon without monsters), you take on a lot of extra responsibility. You 
must create animation sequences for battling the monsters. You also must 
determine how monster attacks affect the player and how you'll handle the 
battle’s results. 


Although programming a simple animation is just a matter of starting a Win- 
dows timer and drawing a new frame for each WM_TIMER message, you must 
also create the images that make up each animation frame. Unless you’re 
artistically inclined, getting such images usually means hiring an artist. (Of 
course, to come up with a decent game, you’ll need an artist, anyway.) 


Aztec Adventure is now just about complete. In its current form, it’s fully 
playable from beginning to end (assuming you add the files needed for floor 
three, which you’ll do in the next chapter). The only thing missing now is 
sound. In the next chapter, you'll see how easy it can be to add sound to a 
Windows game. 


Chapter 12 
Adding Sou 


The real world is overflowing with sound. There’s barely a moment of our 
lives that we’re not barraged with hundreds of different sounds simulta- 
neously. A computer game, of course, can’t hope to compete with the real 
world in the aural department. But, luckily, it doesn’t have to. A few well- 
placed sound effects are all it takes to bring a dungeon alive. 


Ordinarily, programming sound for computer games is extraordinarily diffi- 
cult, due to the fact that there are so many different sound cards on the mar- 
ket. But Windows programmers have the advantage of device independence. 
That is, under Windows, you don’t need to concern yourself with the differ- 
ences between sound cards. You just send Windows a sound, and Windows 
figures out how to play it. 


In this chapter, then, you’ll add the final touches to Aztec Adventure, by 
suturing in a few sound effects. Keep in mind that the sound effects included 
here are by no means the limit of what you can do. You should feel free to 
experiment and add as many other sound effects as you like. 


Recording Sound 


If you’ve never recorded sound effects under Windows before, you're in for 
treat. Not only is the job easy, it’s also fun. Most sound cards come with all 
the software you need to create sound effects for any game that can handle 
WAV files. Moreover, many of these sound-recording programs can also edit 
sounds in various ways, from clipping unwanted noise to adding an echo or 
even reversing a sound effect. 


On my system, I have an Ensoniq Soundscape Wavetable sound card. It 
comes with a sound recording, editing, and playback program called 
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Audiostation (see fig. 12.1). This program can do everything from recording 
WAV files to playing your favorite CD. 


Fig. 12.1 
The Audiostation 
sound application. 


If you have a Sound Blaster 16 sound card, you probably have a program 
called WaveStudio (see fig. 12.2), which, although not as elaborate as 
Audiostation, provides all the basic editing features you need to create sound 
effects for your games. Other types of sound cards come with similar sound- 
editing programs. 


Fig. 12.2 Creative WaveStudio 
Special Window _ Info 


Creative 
WaveStudio. 


Editing Sounds 


No matter what sound card you have and what software you'll be using to 
record and edit sound effects, the first step is to plug a microphone into the 
sound card. Then, whatever sounds the microphone picks up are transmitted 
to the sound card and on to whatever sound-editing program you're running. 


Once you have the microphone plugged in, start up your sound-editing pro- 
gram and turn on the recording function. (You'll need to consult your sound 
program’s documentation for specific instructions on recording sound.) 
Then, the sounds the microphone picks up are converted to WAV file format 
and saved to disk. 


For example, suppose you want to record the words “Welcome, brave adven- 
turer, to the Dungeons of Discovery” to be used as a greeting when the player 
first runs the game. After plugging in your microphone and starting your 
sound program’s record feature, just speak into the microphone (using a suit- 
ably eerie voice, of course). When you’re done speaking, turn off the record 
feature and save your spoken words to a WAV file. You can now play back 
those words with any program that can play WAV files. Soon, you'll see how 
to play back sounds from within your own programs. 


Editing Sounds 


Once you have a sound effect recorded, you’ll almost always need to edit it 
somehow. Different sound programs have different editing features, but most 
of them let you delete various portions of the sound, as well as change the 
volume of the sound. 


One piece of editing you'll almost certainly have to do is delete part of the 
beginning and end of the sound. This is because you’re going to have a sec- 
ond or two of silence before the actual sound wave you want. Why? It takes a 
second or two to go from turning on the sound program’s record function to 
actually creating the sound you want to record. 


Figure 12.3 shows Audiostation ready to delete a silent area from the front of 
a sound effect. The user marked the dark rectangular area with his mouse, in 
much the same way you’d highlight text in a word processor. Then, selecting 
the program’s Cut function, the user deletes the extraneous sound data, as 
shown in figure 12.4. Figure 12.5 shows the same sound wave after the trail- 
ing silence has been deleted. 


Another thing you'll probably have to do is increase the volume of the sound 
effect. For some reason, they never seem to record loud enough. Audiostation 
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has a Scale function that multiplies the amplitude of a sound wave by a factor 
that the user selects in the Scale dialog box (see fig. 12.6). Sound Blaster’s 
WaveStudio has an Amplify Volume function that does the same thing. 

Fig. 12.3 ee Ss 


Deleting part of 
a sound effect. l 


Fig. 12.4 
After deleting the 
leading silent area | 
of the sound 
effect. 


Your sound-editing program may have many other features, as well. Some 
typical extra sound-editing functions include echo and reverse. You should 
also be able to cut and paste pieces of different sound effects together into 
one WAV file. Using this technique, you can come up with some pretty 
strange stuff! 


Generating Sound Effects 431 


[EI WinDAT - (Unten A Fig. 12.5 

: = After deleting the 
trailing silent area 
of the sound 
effect. 


Fig. 12.6 
Scaling a sound 
effect. 
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Generating Sound Effects 


Just like most things in life, the sound effects you create for a game can be as 
simple or elaborate as you want. For most “homegrown” games, you can use 
items that you have laying around the house to generate sound effects. For 
commercial games (games that will be sold in a software store), you'll need a 
full-fledged studio and probably a sound engineer, as well. Now you know 
why the major game companies are always complaining (or boasting) about 
their development costs! 


The sounds that come with Aztec Adventure were generated with a thick, 
metal strip, a screwdriver, a microphone, my voice, and a little creative edit- 
ing. I made the walking sound, for example, just by thumping the micro- 
phone with my hand. I created the door-opening sound by scraping the 
screwdriver against the metal strip. The monster-dissolving effect was created 


432 Chapter 12—Adding Sound 


by striking the metal strip with the screwdriver and then reversing the result- 
ing sound. The other sound effects are simply vocalizations. 


Creating Aztec Adventure, Version 15 


Now that you know how to produce sound effects for Windows games, it’s 
time to install some into Aztec Adventure. You don’t need to actually record 
the sound effects you’ll use in this chapter. They are included on this book’s 
CD-ROM. However, once you see how easy it is to reproduce sound in Win- 
dows programs, you'll probably want to try your hand at improving Aztec 
Adventure’s sonic landscape. 


The complete source code and executable file for this step in the creation of the 
Aztec Adventure application can be found in the CHAP12\AZTEC15 directory of this 
book’s CD-ROM. 


1. Select the Project menu’s Files command and add the WINMM.LIB file, 
located in the MSVC20\LIB directory, to your project (see fig. 12.7). 


Fig. 12.7 
Adding 
WINMM.LIB to WINMM.LIB | 
the Aztec Adven- | ag al a cA Pz | 
ture project.  Lyin32sp ib kee k 
winspool.lib | 
winstrm.lib | 
wsock32.lib ec 
Library Files (* i) 
L J CAMSVC20\aztec\mainfrm. cpp 
| TCAMSVC20\aztec\readme.tet 
C:\MSVC20\aztec\stdafx. ci 


D GM IRS WING 9? LIR. 


The WINMM.LIB file tells the Visual C++ linker important information 
about the functions that you'll be importing from Windows’ multi- 
media extensions. 
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Load the AZTECVW.CPP file and add the following line near the top of 
the file, right after the #endif statement: 


#include <mmsystem.h> 


MMSYSTEM.H is a header file for Windows’ multimedia extensions that 
provides information to Visual C++’s compiler. This information in- 
cludes the prototype for the multimedia function you’ll use in Aztec 
Adventure to play sound. 


Locate the DoMove() function and add the following lines right after the 
call to WinGBitB1t(): 
// Play the footstep sound effect. 
sndPlaySound("FOOTSTEP.WAV", SND SYNC | SND _NODEFAULT) ; 
The preceding line plays the sound effect found in the FOOTSTEP.WAV 
file. You’ll learn more about the sndPlaySound() function later in this 
chapter. 


Locate the OpenDoor() function and add the following lines right after 
the call to WinGBitB1t(): 


// Play the opening-door sound effect. 
sndPlaySound("DOOR.WAV", SND_SYNC | SND _NODEFAULT) ; 


This line plays the sound effect found in the DOOR.WAV file whenever 
the player opens a door. 


Locate the FightMonster() function and add the following lines right 
after the call to WinGBitB1t(): 


// Play the monster-hit sound effect. 
sndPlaySound("HIT.WAV", SND_SYNC | SND _NODEFAULT) ; 


This line plays the sound effect found in the HIT.WAV file whenever 
the player attacks a monster. 


Locate the DoNextMonsterFrame() function and add the following lines 
right after the call to WinGBitB1t(): 


// Play the appropriate sound effect. 
switch (num) 
{ 
case Q: 
sndPlaySound("WOUND.WAV", 
SND_SYNC | SND _NODEFAULT) ; 
break; 
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case 3: 
sndPlaySound("HIT.WAV", 
SND_SYNC {| SND_NODEFAULT) ; 
break; 


} 


These lines play a sound effect whenever the player attacks a monster or 
when a monster attacks the player. 


7. Locate the KillMonster() function and add the following lines right 
after the call to WinGBitB1t(): 
// Play the dissolving-creature sound effect. 
if (i < 3) 
sndPlaySound("DISSOLVE.WAV", SND_SYNC ; SND_NODEFAULT) ; 
This line plays the sound effect found in the DISSOLVE.WAV file when- 
ever the player defeats a monster. 


This completes the final version of Aztec Adventure. To compile the program, 
select the Project menu’s Build command. Visual C++ then compiles and 
links the application. 


Running the Final Version of Aztec Adventure 

Before running the new version of Aztec Adventure, you must add several 
files to your AZTEC directory. Those files are DISSOLVE.WAV, DOOR.WAV, 
FOOTSTEP.WAV, HIT.WAV, WOUND.WAV, LEVELO3.DUN, LEVELO3A.BMP, 
LEVELO3B.BMP, MONST03A.BMP, MONSTO3B.BMP, and MONSTO3C.BMP. 
You can find these files in the CHAP12\AZTEC15 directory of this book’s 
CD-ROM. 


When you run the new version of Aztec Adventure, the main window ap- 
pears. Walk eastward and fight the alligator you'll find there. Cool sound 
effects! After defeating the alligator, continue east until you find a key. Pick 
up the key and go east until you get to a door. Step toward the door and en- 
joy the new sound of the opening gateway. 


Using the sndPlaySound() Function 
As you've no doubt noticed by now, you can play a sound effect by calling a 
single function, called sndPlaySound(): 


sndPlaySound(soundName, flags) 


This function requires two parameters. The first is the name of the file you 
want to play. The function first searches the [sounds] section of the WIN.INI 
file for the sound. The sound names found there are not the names of 
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waveform files, but rather names assigned to specific Windows events. A 
typical WIN.INI [sounds] section looks like this: 
[sounds] 
SystemAsterisk=chord.wav,Asterisk 
SystemHand=chord.wav,Critical Stop 
SystemDefault=C: \WINDOWS\DING.WAV,Default Beep 
SystemExclamation=chord.wav,Exclamation 
SystemQuestion=chord.wav, Question 
SystemExit=chimes.wav,Windows Exit 
SystemStart=tada.wav,Windows Start 


To play the SystemAsterisk sound, you provide sndPlaySound() with the 
string "SystemAsterisk" as its first parameter. If sndPlaySound() can’t find the 
sound represented by the string in WIN.INI, the function assumes that the 
sound string is the name of a waveform file. sndPlaySound() then searches for 
the file in the current directory, the main Windows directory, the Windows 
system directory, or directories included in the user’s PATH environment 
variable. If the function can’t find the file, it tries to play the SystemDefault 
sound, as defined in WIN.INI. Finally, if it can’t find this sound, it returns an 
error. 


The second parameter for sndPlaySound() is the sound-play option, which can 
be one or more of the following: 


Œ sND_syNC—The sound is played synchronously, with the function re- 
turning only when the sound ends. 


Œ snD_ASYNC—The sound is played asynchronously, with the function 
returning immediately after the sound begins. You must call 
sndPlaySound() with a first parameter of NULL to end the sound. 


Œ SND_NODEFAULT—If the sound specified in the first parameter can’t be 
found, the function returns without playing the default sound. 


Œ SND_MEMORY—This parameter indicates that the first parameter in the 
sndPlaySound() call points to a waveform sound in memory. 


Æ sND_LooP—The sound plays repeatedly. To stop the loop, you must call 
sndPlaySound() with a first parameter of NULL. (You must also include 
the SND_ASYNC flag along with SND_LOOP.) 


Œ snD_nostop—The function does not play the requested sound if a sound 
is already playing. In this case, sndPlaySound() returns FALSE. 


435 


436 


Chapter 12—Adding Sound 


The constants used with the multimedia functions, as well as the functions them- 
selves, are defined in MMSYSTEM.H. You must include MMSYSTEM.H in files that use 
these constants and functions. 


Summary 


Creating sound effects for Windows games is easier than you might expect. 
Just plug a microphone into your sound card and run a sound-recording 
program. Every sound that the microphone picks up is recorded by the sound 
program and stored on disk as a WAV (waveform) file. After recording the 
sound, you can edit it in various ways, including deleting parts of the sound, 
increasing the sound’s volume, adding echo, and even reversing the sound. 
To play a WAV file from within your program, you simply call the multi- 
media function sndPlaySound(). 


And that’s it! Congratulations for making it through this book. You now are 
armed with the basic knowledge you need to create 3-D dungeon games (and 
many other kinds of games) for Windows. Along the way, you even learned 
to take advantage of the WinG library, which enables you to create games 
that rival the speed of DOS games. 


But don’t stop here. Take what you've learned and apply it to your own pro- 
gramming projects. Maybe someday I'll read about your latest opus in one of 
the top gaming magazines. Have fun, and don’t let the Fire Snake bite ya! 


Appendix A 
WinG Quick Refe 


The following is a quick reference to the WinG library. Each function is listed along 
with the function’s prototype, an explanation of the function’s purpose, and a 
definition of each of the function’s parameters. For easy reference, the functions 
are listed in alphabetical order. 


BOOL WinGBitB1t(HDC hDCDest, int destX, int destY, int destW, 
int destH, HDC hDCSrc, int srcxX, int srcY) 


This function copies all or part of a WinG bitmap to the destination device 
context, usually the client area of an application’s window. Upon an error, 
WinGBitBl1t() returns FALSE. Otherwise, it returns TRUE. Note that both the 
destination and source device contexts must be in MM_TEXT mapping mode 
when WinGBitB1t() is called. 


Parameter Description 

hDCDest Destination device context 

destX X coordinate of the destination rectangle’s upper left corner 
destY Y coordinate of the destination rectangle’s upper left corner 
destW Width of the destination rectangle 

destH Height of the destination rectangle 

hDCSrc Source WinG device context 

srcX X coordinate of the source rectangle’s upper left corner 


srcy Y coordinate of the source rectangle’s upper left corner 
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HBITMAP WINGAPI WinGCreateBitmap(HDC hWinGDC, 
BITMAPINFO const FAR *pHeader, void FAR *FAR *pBits); 


This function creates a WinG bitmap compatible with the WinG device context 
given in the first parameter. The bitmap is created using the header information 
supplied in a BITMAPINFO structure, a pointer to which is given as the function’s 
second parameter. WinGCreateBitmap() returns a handle to the WinG bitmap, or 
returns a 0 if the function fails. In addition, if the function’s third parameter is not 
O, WinGCreateBitmap() copies the address of the WinG bitmap’s image data into the 
pointer given as the function’s third parameter. 


Parameter Description 


hWinGDC Handle to the WinG device context for which the bitmap 
should be created 


pHeader Address of the BITMAPINFO structure containing the 
bitmap’s attributes 


pBits Address of the pointer into which WinGCreateBitmap () 
should copy the address of the bitmap’s image data 


HDC WINGAPI WinGCreateDC (void); 


This function creates a WinG device context, returning a handle to the DC, or 
returning a 0 if the function fails. Note that a new WinG DC is associated with a 

1 x 1 monochrome bitmap. You should create your own WinG bitmap and select it 
into the WinG DC, retaining a handle to the original monochrome bitmap. Use 
this handle to reselect the original bitmap before deleting the WinG DC. 


HBRUSH WINGAPI WinGCreateHalftoneBrush(HDC hDC, 
COLORREF color, enum ditherType ); 


This function creates a dithered brush based on the colors in a WinG halftone 
palette. The brush’s dither pattern is based on one of three enumerated types: 
WING_DISPERSED_4x4, WING_DISPERSED_8x8, Or WING_CLUSTERED_4x4. The function 
returns a handle to the brush, or returns a 0 if the function fails. 


WinG Quick Reference 


Parameter Description 

hDC Device context with which the brush must be compatible 
color Color that the dithered brush should approximate 
ditherType Dither pattern for the brush; must be WING_DISPERSED_4x4, 


WING_DISPERSED_8x8, or WING_CLUSTERED_4x4 


HPALETTE WINGAPI WinGCreateHalftonePalette(void) ; 


This function creates an 8-bit halftone identity palette, returning a handle to the 
palette, or returning a 0 if the function fails. A halftone palette can be used to dis- 
play 24-bit images on an 8-bit (256-color) device. The WinGCreateHalftoneBrush ( ) 
function creates brushes based on the halftone palette currently selected into the 
device context. 


UINT WINGAPI WinGGetDIBColorTable(HDC hWinGDC, UINT startIndex, 
UINT numEntries, RGBQUAD FAR *pColors) ; 


This function retrieves a set of colors from a WinG bitmap’s color table, returning 
the number of colors retrieved, or returning 0 if the function fails. 


Parameter Description 

hWinGDC Device context into which the bitmap is selected 

startIndex Zero-based index of the first color to retrieve 

numEntries Number of colors to retrieve 

pColors Address of the buffer into which the requested colors will 
be copied 


void FAR *WINGAPI WinGGetDIBPointer (HBITMAP hWinGBitmap, 
BITMAPINFO FAR *pHeader) ; 


This function returns the address of a WinG bitmap’s image data, or returns 0 if the 
function fails. WinGGetDIBPointer() also gets information about the bitmap and 
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stores the information in the BITMAPINFO structure, whose address in given in the 
function’s second parameter. If the second parameter is 0, WinGGetDIBPointer() 
returns only the address of the WinG bitmap. 


Parameter Description 

hWinGBitmap Handle of the WinG bitmap whose image pointer should 
be received 

pHeader Address of a buffer in which to store the BITMAPINFO 


structure for the requested bitmap 


BOOL WINGAPI WinGRecommendDIBFormat(BITMAPINFO FAR *pHeader) ; 


This function determines the type of WinG bitmap that offers the best perfor- 
mance on the current display device. Specifically, winGRecommmendD1IBFormat () sug- 
gests a DIB orientation—bottom-up or top-down—and a pixel format. This pixel 
format is usually 8 bits per pixel under Windows 3.1, although other formats may 
be supported under Windows NT and Windows 95. The suggested DIB orientation 
is stored in the BITMAPINFOHEADER structure’s biHeight member, with —1 meaning 
top-down and 1 meaning bottom-up. The function returns TRUE if successful and 
FALSE upon failure. 


Parameter Description 


pHeader Address of the BITMAPINFO structure into which the 
function will copy the suggested bitmap format 


UINT WINGAPI WinGSetDIBColorTable(HDC hWinGDC, UINT startIndex, 
UINT numEntries, RGBQUAD const FAR *pColors); 


This function sets a series of colors in a WinG bitmap’s color table, returning the 
number of colors changed, or returning 0 if the function fails. 


Parameter Description 


hWinGDC Device context into which the bitmap is selected 


startIndex Zero-based index of the first color to set 


WinG Quick Reference 


Parameter Description 
numEntries Number of colors to set 
pColors Address of the buffer containing the new color values 


BOOL WINGAPI WinGStretchBl1t(HDC hDCDest, int destX, int destY, 
int destW, int destH, HDC ADCSrc, int srcx, int srcY, 
int srcW, int srcH); 


This function copies all or part of a WinG bitmap to the destination device con- 
text, usually the client area of an application’s window. If necessary, 
WinGStretchB1t() scales the bitmap to fit the destination rectangle. Upon an error, 
WinGStretchBlt() returns FALSE. Otherwise, it returns TRUE. Note that both the desti- 
nation and source device contexts must be in MM_TEXT mapping mode when 
WinGStretchBlt() is called. 


Parameter Description 

hDCDest Destination device context 

destXx X coordinate of the destination rectangle’s upper left corner 
destY Y coordinate of the destination rectangle’s upper left corner 
destw Width of the destination rectangle 

destH Height of the destination rectangle 

hDCSrc Source WinG device context 

srcx X coordinate of the source rectangle’s upper left corner 
srcY Y coordinate of the source rectangle’s upper left corner 
srcW Width of the source rectangle 


srcH Height of the source rectangle 
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Probably the most important element of a computer game, aside from its 
playability, is its graphics. The better the graphics, the more the player will 
enjoy the game. In fact, graphics are so important that many mediocre 
games (sorry, no names) become popular solely because of their visual 
appeal. 


Unfortunately, most programmers are about as artistically gifted as chimpan- 
zees with cans of spray paint. Many gifted programmers—those who are 
capable of writing sensational games—simply give up on the idea of game 
programming when they discover their artistic limitations. To create a visu- 
ally appealing game, many programmers resort to hiring artists. 


If this sounds familiar, here’s good news: The graphics often used in com- 
puter games are not particularly difficult to draw. Learning to draw simple 
computer graphics is a lot like learning to make a cake from a mix. Once you 
know how, it’s easy. Much of computer graphic design is a matter of tech- 
nique rather than skill. Of course, a few lessons in computer graphics will 
not make you an artist. If your game requires a lot of detailed graphics, such 
as people, monsters, and buildings, you'll probably still need to find an art- 
ist. But read on. You'll be amazed at how far you can get with just a few 
graphics lessons. 


3-D Made Simple 


Games often boast of “realistic 3-D graphics,” but in fact everything on your 
computer screen is flat and therefore two-dimensional. Although the images 
may seem to be three-dimensional, that effect is an illusion. What this book 
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Fig. B.1 

A simple 3-D 
drawing 
technique. 


Fig. B.2 
Stacking 3-D 
objects. 


refers to as 3-D graphics, then, are simply 2-D images that, like a photograph, 
give the illusion of depth. But before you get into viewpoint, how about a 
quick lesson in basic 3-D computer drawing techniques? 


Some approaches to using graphics to create a sense of depth are very 
simple—so simple, in fact, that they require only a few lines. For example, 
one of the most common and useful 3-D drawing techniques is based on the 
idea that all light comes from above. After all, on Earth, sunlight never comes 
from below, and even artificial light sources are usually placed at or above 
eye level. Therefore, people automatically associate brightly illuminated sur- 
faces with the tops of objects and deeply shaded surfaces with the bottoms. 


Figure B.1 illustrates this principle. Only three colors are used in the drawing: 
white, gray, and black. Gray is the neutral background color, neither high- 
lighted nor shadowed. In the first image, the artist has drawn on the back- 
ground a reversed black “L,” representing two sides of a rectangle. To create a 
3-D illusion for the rectangle in the middle of the figure, the artist completes 
the rectangle with white lines, so that the rectangle seems to protrude from 
the background. To create the last rectangle in the figure, the artist makes a 
similar drawing, but uses white for the base “L” and black to complete the 
rectangle. This rectangle appears to be indented. 


foes 


If you stack such elements (drawing one within the confines of another), you 
can create an illusion of multiple layers and varying depth. As figure B.2 dem- 
onstrates, you can even use this technique to draw buttons that seem to be 
indented when they are selected. 


S| eos 


Using light this way is a useful technique for several reasons. First, it’s easy 

to do. Second, it takes advantage of a universal human sense or perception. 
Third, it’s so simple that you can easily accomplish it through program- 
ming—just by plotting a few lines on the screen—instead of having to draw 
the images in a paint application and then load the image into your program. 
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Creating Simple 3-D Effects 


As you can see, it’s easy to program simple 3-D graphics. However, to create 
more detailed graphics, you must use a paint program. Images drawn with a 
paint program are called bitmapped graphics or just bitmaps. Bitmaps can’t be 
drawn (at least, not very easily) with graphics function calls. Instead, you 
must transfer them to the screen as one complete image. 


There are a lot of techniques for making flat computer graphics seem three- 
dimensional. The most sophisticated require either a lot of artistic skill or 
some very specialized graphics tools (such as a 3-D modeling and rendering 
package). These sophisticated methods are beyond the scope of this book. 
There are, however, some simple, yet effective, techniques that even non- 
artists can use to create good-looking graphics with even the most rudimen- 
tary graphics editors or paint programs. 


The Shadow Technique 

One basic trick for creating a 3-D illusion is to add a simple shadow. This 
shadow is a dark silhouette, identical in shape to the primary object, placed 
so that it appears to be behind the object. You create the illusion of depth by 
offsetting the shadow away from the primary object. You can see this effect 
by drawing a solid white square on top of a solid black square, as shown in 
figure B.3. 


Fig. B.3 
Creating a shadow 
effect. 


Many computer paint programs enable you to create this shadow effect sim- 
ply by copying the object that you’re drawing, coloring the copy darker than 
the original object so that the copy looks like a shadow, and then placing a 
copy of the original object over the new shadow object, as was done with the 
two squares in figure B.3. The original object seems to be closer to you than 
its shadow. 


You can get an even more realistic effect if you scale the shadow down 
slightly to simulate a perspective shift, as in figure B.4. The farther away 
something is, the smaller it looks; consequently, the smaller a shadow is in 
relation to the object casting it, the farther away the shadow appears. 
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Fig. B.4 


Adding greater 


depth toa 
shadow. 


Fig. B.5 
Creating a 3-D 
cube. 


A Variation of the Shadow Technique 

Although the preceding technique is a good way to create a 3-D effect be- 
tween an object and its background, it is not a good method for making the 
object itself look three-dimensional. You can, however, use a variation of the 
shadow technique to draw three-dimensional objects. This variation is similar 
to the pencil-and-paper drawing technique in which you change two overlap- 
ping squares into a cube by adding lines between the corners. 


The images in figure B.S illustrate the principle. First, the artist draws two 
overlapping squares slightly diagonal to each other. Next, the artist draws 
lines connecting the equivalent corners on each square. This results in a 
wireframe cube, which gives the illusion of three dimensions but not of solid- 
ity. To make the cube look solid, the artist must select the square that she 
wants to be in front, and then erase any lines that show through that front 
square and the top and facing squares. (The third cube in the figure shows 
the lines the artist is going to remove in order to form a solid cube.) Presto! 


(UD p 


The less the squares overlap, the longer the object appears to be. (If the start- 
ing squares don’t overlap at all, your drawing won’t look much like a square 
cube, but rather more like a railroad tie.) This drawing technique is not lim- 
ited to squares. You can do the same thing with any shapes, from triangles to 
nonagons and more. The technique works for virtually all geometric shapes— 
except circles and ellipsoids. Because circles and ellipsoids have no corners to 
connect, the technique for making these objects look three-dimensional is a 
little different (see fig. B.6). 


Using Offset Stamping for 3-D Results 447 


Fig. B.6 
Other three- 
dimensional 


objects. 
If you don’t want your 3-D object to look like it just came out of hyperspace, make 
sure to keep the two source objects properly aligned. In other words, don’t rotate 
one object relative to the other, or you may end up with such bizarre results as 
shown in figure B.7. The last time | saw a cube like that, my wife had to drive me 
home from the party! 
Fig. B.7 


An improperly 
drawn 3-D cube. 


Now that you understand a few general principles, you can use them to cre- 
ate more sophisticated computer graphics. In the examples that follow, you 
continue to use the technique of creating a new three-dimensional object by 
connecting two copies of the same object. However, instead of using paper- 
and-pencil drawing techniques, you use the graphics power built into com- 
puter paint programs. 


Using Offset Stamping for 3-D 
Results 


Many game programs use a 3-D viewpoint called three-quarters-view perspective, 
or isometric viewpoint. The creation of such an isometric object is a good sub- 
ject for demonstrating a graphics technique known as offset stamping. 


“Th ffset stamping technique described ag assumes that you have a graphics 
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Fig. B.8 
The offset 
stamping 
technique. 


Fig. B.9 

A 3-D room 
created with 
offset stamping. 


To try offset stamping, first start your paint program and draw a square frame 
(not a filled square). Next, make a small opening in one of the sides to repre- 
sent a door. Now, use your paint program’s clipboard to copy the square, and 
then stamp a copy somewhere else on the screen. Pick a different color than 
you used for the first square and make the copy this new color. You use these 
two squares as source elements when you create a simulated 3-D room. 


To use offset stamping to create the room, copy the square that you recol- 
ored, move to a blank area of the screen, and stamp a copy of the square 
there. Then stamp another copy over the first, just one pixel above and to the 
left of the first, as shown in figure B.8. Do this several times, each time offset- 
ting the stamp the same amount. Next, copy the first square that you drew 
and stamp it onto the stack that you just made, offsetting it as you did the 
other squares. When you’re done, you should have a 3-D room similar to that 
shown in figure B.9. 


[+L 


Combining More Complex Shading with Offset 
Stamping 

You can make your 3-D objects look more realistic by adding more complex 
shading. One good method is to shade the faces of your starting shape with 
different colors and hues before you use the offset stamping technique. Figure 
B.10 shows an example of this shading. In this example, the source of the 
light on the object is above and to the right (as indicated by the sun symbol). 
You use the angle of the light source to determine how bright each object 
surface should be. To make the effect realistic, treat each face like a wall. If 
one side faces the light, make it brighter so that the other side is clearly in 
shadow. 
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ly Fig. B.10 
> c Shading an object 
| before offset 
oO stamping. 
After you finish the shading, use the offset stamping technique to create a 
room. First stack several copies of the shaded object, offsetting each copy by 
one pixel both horizontally and vertically. Then fill the original shaded ob- 
ject with a single color and use that new object to “cap” the stack. If you start 
with the object shown in figure B.10, you end up with objects like those 
shown in figure B.11. As you can see, altering the direction of the offset 
stamping changes the appearance of the object. 
Fig. B.11 


Shaded objects 
created by offset 
stamping. 


You can apply the offset stamping technique to virtually any shape. As the 
examples in figure B.12 show, you can even use offset stamping to create 
round objects (although they require more subtle shading). 


Fig. B.12 

Shaded round 
C) É) objects created by 

offset stamping. 
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Beyond 3-D rooms and objects, you’ll undoubtedly need many other graphi- 
cal objects for your games. Some objects, such as bricks, are fairly simple to 
create. Others, such as teleport squares or glass spheres, require a bit more 
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skill. To help you get started, the rest of this chapter is devoted to basic tips, 
techniques, and tricks that enable you to avoid or solve difficult graphics 
problems. 


Choosing Identifiable Objects 

Sometimes the most difficult task in drawing game graphics is to make an 
object look like the object that it is supposed to look like. Resolution and 
color limitations often complicate your computer graphics drawing, but 
sometimes just figuring out how to symbolize an object can drive you to the 
medicine cabinet for aspirin. 


For example, your game design might call for the hero to wear a pair of ultra- 
violet contact lenses that enables him to see certain other game objects. But 
contact lenses, being little more than glass disks, are difficult to render realis- 
tically. Would you recognize a graphic of contact lenses, no matter how well 
it was drawn? A glass disk can represent so many other objects that its visual 
meaning is ambiguous. 


In such circumstances, you should find a more easily identifiable object to 
replace the ambiguous object in your game. You might, for example, use 
eyeglasses in your game instead of contact lenses. A player is not likely to 
mistake a pair of eyeglasses for any other object. 


Designing Icons 

Creating icons for computer programs can be tougher than climbing a 
greased tree. Although a sword icon clearly represents fighting and a scissors 
icon obviously represents some kind of cutting function, how can you repre- 
sent less “visual” functions, such as saving a game or displaying a high-score 
board? 


Unfortunately, designing icons is a skill that can’t be taught. It requires much 
imagination and a lot of trial and error. For icons, a picture is clearly not 
worth a thousand words! Obviously, when designing icons, you should strive 
for simple, unambiguous images that easily identify their associated func- 
tions. If you can’t come up with such images, you're far better off to use text 
labels rather than icons. Few things in computer interfaces are more annoy- 
ing than poorly designed icons. 


Drawing Metal 

Believe it or not, drawing metal surfaces is one of the easiest tasks in com- 
puter graphics, provided you have two or more shades of a specific color 
available. For flat metal surfaces, just draw diagonal highlights on the object. 
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If you have more than two shades available, you can get more complex, alter- 
nating highlights by using darker reflections. Figure B.13 demonstrates this 
metal drawing technique. The more shades of a specific color you use, the 
more effective your result will be. 


/ Fig. B.13 
Wy Z Wy Using highlights 
Hi and reflections 
á to draw metal 


surfaces. 


You can use similar techniques to draw curved metal surfaces, but you must 
follow slightly different rules. First, highlights must appear near the edge 
closest to the light, and shadows must appear near the edges farthest from 
the light. Figure B.14 shows how you can make a cylinder appear metallic by 
changing hues and placing highlights appropriately. Notice that the harsh 
shadow along the dark left side of the cylinder softens to a lighter shade at 
the rim, which produces a more reflective look. 


Fig. B.14 
Drawing a curved 
metal surface. 


Because they are reflective, most metals display severe highlights and shad- 
ows. In other words, the more smoothly and evenly you blend shades one 
into another, the less metallic a surface appears. Adding specular highlights or 
“hot spots” (extremely bright points of reflected light, as seen in fig. B.14) 
helps make surfaces look more metallic. 


Drawing Glass 

Because glass is transparent, you don’t draw glass any more than you draw 
air. What you do draw is the effect that glass has on objects that are seen 
through it. Often, the simplest way to create a glass object is to draw its gen- 
eral shape and then add highlights and shadows as you did when drawing 
metal. You then draw what shows through the glass, highlighting and shad- 
ing it appropriately. 


Figure B.15 shows how this works. You draw the bottle in light gray with 
white highlights and dark gray shadows. Then you draw the liquid within 
the bottle by replacing the bottle’s colors with different shades, but leaving a 
slim line of the original color at the perimeter of the bottle to show the thick- 
ness of the glass. The result looks transparent. 
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Fig. B.15 


Drawing glass. 


Fig. B.16 


Using reflections, 
degradation, and 
distortion to draw 


objects seen 
through glass. 


Because glass is reflective, you can create glass surfaces by placing highlights 
on the glass object, similar to those that you use to create metal surfaces. 
Highlights can either obscure objects seen through the glass or allow those 
objects to show through. If the object seen through the glass extends beyond 
the glass, you should degrade the image that shows through the glass, by 
drawing that part of the object with slightly lighter colors. This is because 
glass is not perfectly transparent, and thus captures a tiny amount of light. 
This loss of light makes an image seen through glass look slightly dulled, as 
though it has lost some of its color. Also, glass sometimes bends light passing 
through it, resulting in some distortion of the image. To create this distor- 
tion, you often draw the part of the object behind the glass slightly enlarged, 
as though the glass were magnifying it. 


Figure B.16 demonstrates the use of reflection, degradation, and distortion. 
The figure shows part of a metal rod as seen through a pane of glass. 


Drawing Luminous Objects 

You can take advantage of several tricks when drawing luminous objects such 
as light bulbs or flaring stars. But, if you’re not careful, you may end up with 
a strange-looking object, indeed. For example, if you draw a glow around a 
light bulb, almost anyone can tell that the light bulb is glowing. However, 
place the same glow around an object shaped like a sheep, and you get a 
lamb in need of shearing. Still, the glow effect is useful if used sparingly. 


One of the best ways to create a luminous object is to draw the effect of the 
emitted light on the object’s surroundings. For example, a glowing light- 
emitting diode (LED) is just a brightly colored blob. The only way you can 
show that the LED is lighted is by drawing the effects of the LED’s light on its 
surroundings. Likewise, when you draw a knight wielding a glowing sword, 
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the sword should throw highlights on the knight while casting other parts of 
the figure into shadow. Figure B.17 shows these types of objects. 


Fig. B.17 


objects. 


Fire, another type of glowing object, is difficult to draw because one of its 
distinguishing characteristics is its motion—the dance of the flame. Often, a 
static representation of flame looks like anything but fire. The colors that you 
use when drawing fire also can have a profound effect on the end result. The 
wrong hues may make your fire look more like a popsicle. There are few good 
rules for drawing fire. Your best bet is to stick with the colors that people 
automatically associate with fire (reds and oranges) and place flames within 
recognizable contexts, such as camps, fireplaces, and torches. 


Drawing Drop Shadows 

A drop shadow is a shadow that you place under an item that you have 
drawn. Drop shadows are useful for a couple of reasons. First, if an object’s 
drop shadow is immediately beneath and connected to the object, you can 
tell that the object is resting on the ground (or some other surface). Con- 
versely, when an object’s drop shadow is disconnected from and farther be- 
low the object, the object appears to be floating in the air. 


There’s not much to say about drop shadows. They’re generally dark spots, 
often black, that appear around the base of an object or below an airborne 
one. The simplest drop shadows, such as those used in cartoons, are just 
spots. However, more elaborate drop shadows mimic the casting object’s 
shape. Figure B.18 provides a couple of examples. 


Fig. B.18 
D Drawing drop 
Ee. shadows. 
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Working with Limited Colors 

All the programs in this book run in the high-resolution (640 x 480), 256- 
color VGA graphics mode. But, when programming games, you may some- 
times find yourself restricted to as few as 16 colors—not much to work with. 
If your game runs in this mode (rather than 256-color mode) and requires 
objects ranging from metal and mortar to monsters and men, you may be 
stumped as to how to draw everything that you need with so few colors. 


To tackle this problem, first make a list of graphics elements that you need 
for the game, and then see which colors they have in common. For example, 
if you need foliage, you probably want a shade or two of green. Can you use 
green for something else, like a slime monster or a dragon? The idea is to use 
as few colors as possible, of course, so that if you later discover you need a 
color you haven’t previously defined, a color register or two will still be 
available. When you finish drawing all your graphics, you may find that you 
haven’t used all 16 colors. If so, decide where you’d like some additional 
detail, and then use those extra colors where they’ll make the most 
difference. 


Another trick for extending your color choices is to use dithering. You create 
dithered colors by mixing two colors together. For example, mixing red and 
blue creates a shade of purple. Of course, the colors in your paint program 
can’t really be mixed like real paint. However, if you create a fill pattern com- 
prised of pixels of alternating color, like the enlargement shown in figure 
B.19, you can create the mixing effect. At normal size, the dots are so close 
together that the human eye sees them as one color. 


Fig. B.19 
Creating dithered 
colors. 


Smoothing Graphics 

All display graphics on the PC are raster displays; that is, they are composed 
of thousands of illuminated dots on a vast grid. Therefore, the only perfectly 
smooth lines that you can draw are horizontal or vertical lines. Any line that 
deviates from perfect horizontal or vertical orientation is drawn across a series 
of rows and columns and appears to consist of staggered line fragments with 
obvious “stairsteps.” This stairstep effect is known as an alias (or colloquially 
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as a “jaggie,” because of its jagged look). The technique that you use to dis- 
guise the alias effect is called antialiasing. 


Antialiasing blurs the edges of each stairstep by placing a pixel or pixels of an 
intermediate color or tone at the end of each alias. For example, to smooth 
the aliases between a blue and a red area, you place a purple pixel at each 
“stairstep” juncture. 


Figure B.20 demonstrates antialiasing on a black circle. The left circle of each 
pair is drawn black on white with no antialiasing. The right circle of each pair 
is antialiased, with two or more shades of gray used to blur the stairsteps. 
When enlarged, as in the pair of circles on the right, the antialiasing looks 
odd. However, when viewed at normal scale on a computer screen, as shown 
in the pair of circles on the left, antialiasing works wonderfully to reduce and 
even remove the stairstep effect. 


Fig. B.20 
Antialiasing at 
work. 


Many paint programs have a built-in feature for antialiasing part or all of a 
screen or graphic. Most such antialiasing functions do a fairly good job, but 
like any automated procedure, sometimes you may not get the exact effect 
that you want. In such circumstances, you may have to retouch the 
antialiasing or even redo it from scratch. 


Overusing antialiasing can result in fuzzy images. The fewer pixels that you use to 
draw an item, the more likely it is to become fuzzy when antialiased. Also, high- 
contrast images often look slightly “muddy” when antialiased. 


Finally, if you antialias a graphic before placing it on its final background, you may 


get unexpected and unappealing results. Because the colors used in antialiasing are 
intermediate, placing a graphics element onto a different background color changes 
the antialiasing effect. You should make antialiasing the final step in preparing graph- 
ics. (Keep a copy of the original image, free of antialiasing, in case you have to make 
major changes or dislike the antialias effect.) 
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Summary 


Although it takes many years of study and practice to become a competent 
computer artist, you can quickly learn several handy techniques for drawing 
effective—albeit simple—game graphics. These techniques include highlight- 
ing, shading, offset stamping, antialiasing, and dithering. You can combine 
all of these effects to create many types of pseudo 3-D objects. These tech- 
niques even enable you to draw metal and glass surfaces. 


Appendix C f 
Aztec Adventure ` 
Complete Listings 


Here are the complete listings for the Aztec Adventure game. In these listings, 
code that you added manually is shown between double lines of slash charac- 
ters. Code that you added using ClassWizard is listed normally—that is, it is 
not shown between double lines of slash characters. Files that were created by 
AppWizard, but which you did not modify, are not shown here. If you’d like 
to know what the unlisted files contain, load them from disk using Visual 
C++ or some other text editor. 


Listing C.1 AZTEC.H—Header File for the CAztecApp Class 


// aztec.h : main header file for the AZTEC application 
// 


#ifndef _ _AFXWIN_H_ _ 


#error include ‘stdafx.h' before including this file for PCH 
#endif 


#include "“resource.h" // main symbols 


LIILIA TTT ATT TTT TTT AAT 
[ILILILILIL 
// START CUSTOM CODE 

LASAITA CUA UIIE AATAL 
TITTTTTTTTTT ITAA TATA TTT TATA TTT 


enum { North, East, South, West }; 
const DUNGEONSIZE = 1024; 


const ROWSIZE 32; 
const COLSIZE 32; 


(continues) 
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Listing C.1 Continued 


enum {Empty, Wall, Door, Key, Monster, 
Treasure, Sword, Armor, Potion}; 


struct CItem 

{ 
WORD iType; 
WORD iNumber; 
WORD iValue; 

}; 


[IIIIIIIIL I IIIN IIIA 
FITTLTTTTTTT TTT TAT TATA ATA AAT 
// END CUSTOM CODE 

[ILILILILIL TTT TATA TAT 
FITTTTTTTTTTT TTT TTT TT 


FILTLTTATTTT TTT AAA TATA AAA ATT ATA TAA 
// CAztecApp: 

// See aztec.cpp for the implementation of this class 

// 


class CAztecApp : public CWinApp 
{ 
public: 

CAztecApp() ; 


// Overrides 
// ClassWizard generated virtual function overrides 
//{{AFX_VIRTUAL (CAztecApp) 
public: 
virtual BOOL InitInstance() ; 
//}}AFX_VIRTUAL 


// Implementation 
//{{AFX_MSG(CAztecApp) 


afx_msg void OnAppAbout() ; 
// NOTE - the ClassWizard will add and remove member functions 


// here. 
// DO NOT EDIT what you see in these blocks of generated 
// code ! 


//}}AFX_MSG 
DECLARE_MESSAGE_MAP( ) 
}; 


[ILILILILIL TAAL A AAA TATA TAAL 


Aztec Adventure Complete Listings 


Listing C.2 MAINFRM.CPP—Implementation File for the 


CMainFrame Class 


// mainfrm.cpp : implementation of the CMainFrame class 
// 


#include "stdafx.h" 
#include "“aztec.h" 


#include "mainfrm.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED_CODE THIS_FILE[] = _ _FILE_ _; 
#endif 


FILTTITTTITTT TTT TATA AAA ATTA AAA AL 
// CMainFrame 


IMPLEMENT_DYNCREATE(CMainFrame, CFrameWnd) 


BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) 
//{{AFX_MSG_MAP (CMainFrame) 
ON_WM_PALETTECHANGED ( ) 
ON_WM_QUERYNEWPALETTE ( ) 

/ /}}AFX_MSG_MAP 

END_MESSAGE_MAP() 


POCANNAN ANIA TTT TATA AAT ATA ATA AAA 
// CMainFrame construction/destruction 


CMainFrame: :CMainFrame() 


// TODO: add member initialization code here 


} 


CMainFrame: :~CMainFrame() 
{ 
} 


[IILI TTT TTT TTT ATA AAA AAA AA AAA AAT 
// CMainFrame diagnostics 


#ifdef _DEBUG 
void CMainFrame: :AssertValid() const 


{ 
CFrameWnd: :AssertValid() ; 
} 
void CMainFrame: :Dump(CDumpContext& dc) const 
{ 
CFrameWnd: :Dump (dc); 
} 


(continues) 


459 


460 Appendix C—Aztec Adventure Complete Listings 


Listing C.2 Continued 


#endif //_DEBUG 


FISICI TATA TATA ATTA TAT TAL 
/{ CMainFrame message handlers 


BOOL CMainFrame: :PreCreateWindow(CREATESTRUCT& cs) 


{ 
// TODO: Add your specialized code here and/or call the base class 


FELTTTTTTTTT AAAA AALA ATTA 
[ILILILILIL 
// START CUSTOM CODE 

[IIIIIIIIIIII IIIA 
CINITI II A A CITAN AATA ATEI 


// Set the window's size. 
cs.cx = 550; 
cs.cy = 468; 


// Set the window's style. 
cs.style = WS OVERLAPPED | WS_CAPTION | 
WS_SYSMENU {| WS_MINIMIZEBOX; 


FULTTTTTTTTT TTT AT TTT TATA TATA TL 
TIITITTTTTTT TTT TTT TTT TAAL 
// END CUSTOM CODE 

IILI EAA TTT 
VANIA AATU IIA A AAA TTT 


return CFrameWnd: :PreCreateWindow(cs) ; 


} 


void CMainFrame: :OnPaletteChanged(CWnd* pFocusWnd) 


{ 
CFrameWnd: :OnPaletteChanged (pFocusWnd) ; 


// TODO: Add your message handler code here 


SILITA ANNEANNE LAT 
FITTTTTTTTT TTT TTT TATA ATTA TATA TTL 
// START CUSTOM CODE 

[III I TTT TTT TTT TATA AAA AAT ATL 
[IILI III IIIA 


// Get a pointer to the view window. 
CView* pView = GetActiveView() ; 


// If it isn't the view window changing 

// the palette, redraw the view window with 

// the newly mapped palette. 

if (pFocusWnd != pView) 
pView->Invalidate(FALSE) ; 
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TITTTTTTTTTTTTT TTA TTT TTT TAT 

TTLTTTTTTTTTT TTT TTT ATTA TATA TT 

// END CUSTOM CODE 

[IIIT TTT TTT TTT 

[ILILILILIL 
} 


BOOL CMainFrame: :OnQueryNewPalette() 


{ 
// TODO: Add your message handler code here and/or call default 


CIATTE TATAA T TTT AAT TTT 
FILTET LIT AAA AIEA TEATEIL I 
// START CUSTOM CODE 

[ILILILILIL TTT TTT TTT ATT TT 
TLTTTTTTTTTTTTT TTT AASIAATI TTT 


// Get a pointer to the view window. 
CView* pView = GetActiveView() ; 


// Redraw the view window with its own colors. 
pView->Invalidate(); 


TTTTTTTTTTTTTT TTT TAT TAT 
CIITA TTT TTT TT 
// END CUSTOM CODE 

[ILIITA 
COITIANTA ELTAC TT 


return CFrameWnd: :OnQueryNewPalette(); 


Listing C.3 AZTECDOC.H—Header File for the CAztecDoc Class 


// aztecdoc.h : interface of the CAztecDoc class 
// 
FILTLITTTTTT TTT TTT TTT TAA AAA AT AAT 


FIETTTTTTTTTTT TTT TTT TTT TATA AT 
CIIU TIS ETET PEETELI 
// START CUSTOM CODE 

[ILILILILIL 
LEII AANA E AAAA EEEIEE 


#include "cdib.h" 


FELTTTTTTTTTTTTTT TTT TTT TTT 
FELTLTTTTTTTT TTT TTT TAAL TTT TTT 
// END CUSTOM CODE 

LIILIA TTT TTT TTT ATT TAT 
TLTTITTTTTTTTT TATA TTT ATTA TTT TT 


(continues) 
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Listing C.3 Continued 


class CAztecDoc : public CDocument 


protected: // create from serialization only 
CAztecDoc() ; 
DECLARE_DYNCREATE (CAztecDoc ) 


// Attributes 
public: 


FTLITTTTITTTT TTT TTT TATA ATTA TTT 
TATICI IEE AAA AAAA AA ATEN 
// START CUSTOM CODE 

PECCA CAAA IANA EAA TL 
[ILIIIIIIIII ITIITI 


CDib* m_pPartsADib; 
CDib* m_pPartsBDib; 
UINT m_playerX, m_playerY; 
UINT m_faceDir; 

UINT m_floorNum; 
CPtrArray m_Dungeon; 
CDib* m_pPanelDib; 
CDib* m_pSundryDib; 
BYTE* m_pPanelBits; 
BYTE* m_pSundryBits; 
BOOL m_keys[6]; 

UINT m_potionValues[6]; 
UINT m_potionCount ; 
CDib* m_pMessageDib; 
UINT m_curSword; 

UINT m_curArmor; 

BOOL m_hasSword; 

BOOL m_hasArmor; 

UINT m_playerLevel; 
UINT m_playerGold; 
UINT m_playerExper; 
UINT m_playerDefense; 
UINT m_playerAttack; 
int m_playerHP; 

CDib* m_pMonsterADib; 
CDib* m_pMonsterBDib; 
CDib* m_pMonstercDib; 
BYTE* m_pMonsterABits; 
BYTE* m_pMonsterBBits; 
BYTE* m_pMonsterCBits; 


protected: 
CString* m_pLevelFileName; 
BOOL m_gameOver; 


TTLTTTTTTTTTT TTT TTT TTT TAT 
[ILILILILIL III TTT TTT TTT TTL 
// END CUSTOM CODE 
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[ILILILILIL 
TIILI A AAAA AEEA TIA 


// Operations 
public: 


TULTTTTTTTTTT TTT TATA TAT 
TTLTTTTTTTTTT TTT TAT TATA TT 
// START CUSTOM CODE 

FUTTTTTTTTTT TTT TTT TTT 
[ILLITE 


BOOL StartNextFloor(); 


[ILILILILIL 
[ILILILILIL 
// END CUSTOM CODE 

FUTTTTTTTTTTT TTT TATA TTT TTA TT 
[ILILILILIL 


// Overrides 
// ClassWizard generated virtual function overrides 
//{{AFX_VIRTUAL (CAztecDoc) 
public: 
virtual BOOL OnNewDocument() ; 
virtual void DeleteContents(); 
//}}AFX_VIRTUAL 


// Implementation 
public: 
virtual ~CAztecDoc(); 
virtual void Serialize(CArchive& ar); // overridden for document i/o 
#ifdef _DEBUG 
virtual void AssertValid() const; 
virtual void Dump(CDumpContext& dc) const; 
#endif 


protected: 


[ILILILILIL 
[ILILILILIL 
// START CUSTOM CODE 

FTTTTTTTTTTTTT TTA TTT TTT ATT 
FITTTTTTTTTTT TTT TTT TTT TTT 


void LoadLevel(); 
void LoadFloorDIBs(UINT floor); 
void DeleteFloorDIBs(); 


TIITLTTTTTTTT TTT TATA TTT TAT 
[ILILILILIL 
// END CUSTOM CODE 

TTLTTTTTTTTTT TTT TTT TTT ATA 
TTTTTTTTTTTTT TTT ATTA TTT TTT 


(continues) 
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Listing C.3 Continued 


// Generated message map functions 
protected: 
//{{AFX_MSG(CAztecDoc) 
// NOTE - the ClassWizard will add and remove member functions 


// here. 
// DO NOT EDIT what you see in these blocks of generated 
// code ! 


/ /}}AFX_MSG 
DECLARE_MESSAGE_MAP() 


}; 
/IIIII11IIIIII LILIA 


hena e ee o e S e e ae AE EE S Se raae a a aE 


Listing C.4 AZTECDOC.CPP—Implementation File for the 


CAztecDoc Class 


// aztecdoc.cpp : implementation of the CAztecDoc class 
// 


#include "stdafx.h" 
#include "aztec.h" 


#include "“aztecdoc.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED CODE THIS _FILE[] = _ _FILE_ _; 
#endif 


FULTITLITL TTT TTT TTA AAA AAT ATTA TTT AAT TTT TL 
// CAztecDoc 


IMPLEMENT_DYNCREATE(CAztecDoc, CDocument) 
BEGIN _MESSAGE_MAP(CAztecDoc, CDocument) 


//{{AFX_MSG_MAP (CAztecDoc) 
// NOTE - the ClassWizard will add and remove mapping macros 


// here. 
// DO NOT EDIT what you see in these blocks of generated 
// code! 


/ /}}AFX_MSG_MAP 
END_MESSAGE_MAP() 


eee 
// CAztecDoc construction/destruction 


CAztecDoc: :CAztecDoc() 
{ 


// TODO: add one-time construction code here 


CAILLA ANNAT ANA ANNALI A AN 
TTLTTTTTTTTTT TTT TTT ATT TTA TTL 
// START CUSTOM CODE 

FTTTTTTTTTTTTT TTT TTT ATT TATA AAT 
PAILAN ELA AAA TANAIT AAT 


//m_pPartsADib = new CDib("LEVEL@1A.BMP"); 
//m_pPartsBDib = new CDib("“LEVELQ1B.BMP"); 


m_pLevelFileName = new CString("LEVELQ@1.DUN") ; 


m_gameOver = FALSE; 

m_pPanelDib = new CDib("panel.bmp"); 
m_pSundryDib = new CDib("sundry.bmp"); 
m_pMessageDib = new CDib("message.bmp") ; 


m_pPanelBits = m_pPanelDib->GetDibBitsPtr() ; 
m_pSundryBits = m_pSundryDib->GetDibBitsPtr(); 


LoadFloorDIBs(1) ; 


[IIIN 

FITTTTTTTTTTTTT TTT TTT 

// END CUSTOM CODE 

LTTTTTTTTTTTTTT TTT TTT ATTA TTT 

[ILILILILIL IIIN 
} 


CAztecDoc: :~CAztecDoc() 

{ 
TAIATEA LITTA 
TITTITITTTTT TTT TTA TAA TTI AT 
// START CUSTOM CODE 
[I/III I IIIN 
TAA LAA LETITI ITANE FEAT ILEFELEETE EEIT 


//delete m_pPartsADib; 
//delete m_pPartsBDib; 
delete m_pLevelFileName; 
delete m_pPanelDib; 
delete m_pSundryDib; 
delete m_pMessageDib; 
DeleteFloorDIBs(); 


VANITA ATTA ECNIN AATA. 

[IITTI ITIITI 

// END CUSTOM CODE 

PALALI S AIAT AAA AATAS IICT TAIE. 

TILILA IIAN ATVN AEAT ACET. 
} 


BOOL CAztecDoc: :OnNewDocument ( ) 


if (!CDocument: :OnNewDocument () ) 
return FALSE; 


// TODO: add reinitialization code here 
// (SDI documents will reuse this document) 
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(continues) 
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Listing C.4 Continued 


TIAIA TAAIE ATAATA EAA TL 
[1I1IIIIIIII IIIA 
// START CUSTOM CODE 

FTLITLTTTLT TTT TTT TATA AAT AAT ATT 
TIFLA TTT TTT TATA A TAA TT 


// Initialize game variables for a new game. 
m_floorNum = 1; 


m_playerxX = 1; 
m_playeryY = 1; 
m_faceDir = East; 


m_potionCount = 0; 


m_curSword = Q; 
m_curArmor = Q; 
m_hasSword = FALSE; 
m_hasArmor = FALSE; 


for (UINT i=@; i<6; ++i) 

{ 
m_keys[i] = FALSE; 
m_potionValues[i] = 0; 


} 


// Initialize player statistics. 
m_playerLevel = 1; 

m_playerGold = Q; 

m_playerExper = 0; 

m_playerHP = 100; 
m_playerDefense = 0; 
m_playerAttack = Q; 


// Initialize the game-over flag. 
m_gameOver = FALSE; 


// Initialize floor-bitmap pointers. 


m_pPartsADib = 0; 
m_pPartsBDib = 0; 
m_pMonsterADib = 0; 
m_pMonsterBDib = 0; 
m_pMonsterCDib = Q; 


// Load the bitmaps for floor 1. 
LoadFloorDIBs (1); 


// Set the file name for floor 1. 
*m_pLevelFileName = "LEVEL@1.DUN"; 


// Load data for the current floor. 
LoadLevel() ; 


// Notify the view of a change in the document. 
UpdateAll1Views (NULL) ; 
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SISULT IAA TTT AAEL A 
TTTTTTTTTTTTT TTT TTT TTT ATTA ATT 
// END CUSTOM CODE 

TITTTTTTTTTTTTT TTT TTT TTA TATA 
[ILILILILIL 


return TRUE; 
} 


LIA FINLLIIII TIETAN ANAA ILIAN IANN AAA AAT CEIL LAITIITI 
// CAztecDoc serialization 


void CAztecDoc: :Serialize(CArchive& ar) 


{ 
if (ar.IsStoring()) 
{ 
// TODO: add storing code here 
} 
else 
{ 
// TODO: add loading code here 
} 
} 


[IIIN II TIINAN 
// CAztecDoc diagnostics 


#ifdef _DEBUG 
void CAztecDoc::AssertValid() const 


{ 
CDocument: :AssertValid() ; 
} 
void CAztecDoc: :Dump(CDumpContext& dc) const 
{ 
CDocument: :Dump(dc) ; 
} 


#endif //_DEBUG 


PILTTITTTTTTT TTT TTT TTT TTA TATA AAT AAA AAT 
// CAztecDoc commands 


[IIIT 
CISIT TAITEELLA EIA ATIAEINA 
// START CUSTOM CODE 

I/III 
VISIITI AITITA AIEA CEIC AT 


void CAztecDoc: :LoadLevel() 


{ 
CFile file; 
char far* pFileName; 


// Get a pointer to the current file name. 
pFileName = m_pLevelFileName->GetBuffer (12) ; 


(continues) 
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Listing C.4 Continued 


} 


// Open the dungeon data file for the current floor. 
BOOL opened = file.Open(pFileName, CFile: :modeRead) ; 


// If the file opened okay... 
if (opened) 


// Construct an archive object from the file. 
CArchive ar(&file, CArchive::load) ; 


// Read all dungeon items and add them 
// to the item array. 
for (int i=; i<DUNGEONSIZE; ++i) 


{ 
CItem* pItem = new Citem; 
ar >> pItem->iType; 
ar >> pItem->iNumber; 
ar >> pItem->iValue; 
m_Dungeon.Add(pItem) ; 

} 


// Close the archive object and the file. 
ar.Close(); 
file.Close(); 

} 


// If there's an error loading the data, 
// end the game. 
else 

m_gameOver = TRUE; 


[III II IIIT 
[ILII IIIA 
// END CUSTOM CODE 

FELTTTTTTTTTTT TTT T LICA AITA AATTEENA 
FETTLTTTT TTT TTT TTT TTT ATTA TT 


void CAztecDoc: :DeleteContents() 


{ 


// TODO: Add your specialized code here and/or call the base class 


[ILILILILIL IIIT 
FILETTLTTTTT TTT TTT TTT ATT TD 
// START CUSTOM CODE 

FLLLTLTTTTTTT TTT TTT TTT TATA TT 
[ILILILILIL IIIT 


// Get the number of elements in the m_Dungeon array. 
UINT size = m_Dungeon.GetSize(); 


// If the array isn't empty, delete its contents. 
if (size > 0) 


{ 


} 
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for (int i=; i<DUNGEONSIZE; ++i) 
delete m_Dungeon.GetAt (i) ; 
m_Dungeon.RemoveA11() ; 


} 


// Delete the bitmaps associated with the current floor. 
DeleteFloorDIBs(); 


ISILELI TTT TATA TTT AAT 
IA MAA DALIA AA AATA ACEEEO 
// END CUSTOM CODE 

TITTTTTTTTTT TTT TTT TTT TAT TATA TT 
CINTU CINTEN INEI TATA TA TTT 


CDocument: :DeleteContents(); 


TULTTTTTTTTTT TTT TTT TTA TTT TL 
FITTTTTTTTTTTT TTT TTT TTT TTT ATTA TTT 
// START CUSTOM CODE 

VIIULIT CIANA ITTI 
TATEAN TAIATI EAA ANCE. 


void CAztecDoc::LoadFloorDIBs(UINT floor) 


{ 


// Convert the floor number to a string. 
char s[5]; 
wsprintf(s, "%d", floor); 


// Create a file-name CString object. 
CString floorFileName("LEVELXXA.BMP") ; 


// Add the floor number to the file name. 
if (floor < 10) 


floorFileName.SetAt(5, '@'); 
floorFileName.SetAt(6, s[@]); 


} 
else 
floorFileName.SetAt(5, s[Q@]); 
floorFileName.SetAt(6, s[1]); 
} 


// Construct a CDib object from the "Parts A" bitmap. 
m_pPartsADib = new CDib(floorFileName) ; 


// Change the file name for the "Parts B" bitmap. 
floorFileName.SetAt(7, 'B'); 


// Construct a CDib object from the "Parts A" bitmap. 
m_pPartsBDib = new CDib(floorFileName) ; 


// Change the file name for the "Monster A" bitmap. 
floorFileName.SetAt(@, 'M'); 
floorFileName.SetAt(1, '0'); 
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Listing C.4 Continued 


floorFileName.SetAt(2, 'N'); 
floorFileName.SetAt(3, 'S'); 
floorFileName.SetAt(4, 'T'); 
floorFileName.SetAt(7, 'A'); 


// Construct a CDib object from the "Monster A" bitmap. 
m_pMonsterADib = new CDib(floorFileName) ; 


// Load the "Monster B" bitmap. 
floorFileName.SetAt(7, 'B'); 
m_pMonsterBDib = new CDib(floorFileName) ; 


// Load the “Monster C" bitmap. 
floorFileName.SetAt(7, 'C'); 
m_pMonsterCDib = new CDib(floorFileName) ; 


// Initialize pointers to the monster image data. 
m_pMonsterABits = m_pMonsterADib->GetDibBitsPtr () ; 
m_pMonsterBBits m_pMonsterBDib ->GetDibBitsPtr() ; 
m_pMonsterCBits = m_pMonsterCDib->GetDibBitsPtr () ; 


} 


void CAztecDoc: :DeleteFloorDIBs() 
{ 
// Delete the bitmaps associated with the current floor. 
delete m_pPartsADib; 
delete m_pPartsBDib; 
delete m_pMonsterADib; 
delete m_pMonsterBDib; 
delete m_pMonsterCDib; 


// Reinitialize all of the CDib pointers. 
m_pPartsADib = @ 
m_pPartsBDib = 0 
m_pMonsterADib = 
m_pMonsterBDib = 0; 
m_pMonsterCDib = 0 


} 


BOOL CAztecDoc: :StartNextFloor() 

{ 
// Reinitialize game variables. 
m_playerxX = 1; 
m_playeryY = 1; 
m_faceDir = East; 
m_potionCount = 0; 


for (UINT i=; i<6; ++i) 

{ 
m_keys[i] = FALSE; 
m_potionValues[i] = 0; 
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// Increment the floor number. 
++m_floorNum; 


// Convert the floor number to a string. 
char s[5]; 
wsprintf(s, "%d", m_floorNum) ; 


// Construct the file name for the new floor-data file. 
if (m_floorNum < 10) 


{ 
m_pLevelFileName->SetAt(5, '@'); 
m_pLevelFileName->SetAt(6, s[@]); 
} 
else 
{ 
m_pLevelFileName->SetAt(5, s[@]); 
m_pLevelFileName ->SetAt(6, s[1]); 
} 


// Delete the contents of the old m_Dungeon array. 
DeleteContents(); 


// Load the new data into the m_Dungeon array. 
LoadLevel(); 


// If the new level data was found, load 
// the associated bitmaps. 

if (!m_gameOver) 

{ 


} 


LoadFloorDIBs(m_floorNum) ; 


return m_gameOver; 


} 


TTLTTTTTTTTTTTT TTT TTT TTT 
LIILIA EET CEI EI AAAA AT TL 
// END CUSTOM CODE 

TTTITTTTTTTTT TTT TTT TTA TTT 


TITTTITTTTTTT TTT TATA TATA AAT 


Listing C.5 AZTECVW.H—Header File for the CAztecView Class 


// aztecvw.h : interface of the CAztecView class 
// 
ILLIC NLANLA CANAAN E TTT TATA 


TTLITTTTTTTTTT TTT TTT TTT TTT 
[ILII IINIT 
// START CUSTOM CODE 

[LILII TTT AAA 
TTITTTTTTTTTTTTT TTT TTT ATTA TT 


#include "“c:\wing\include\wing.h" 


(continues) 
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Listing C.5 Continued 


const WINGDIBWIDTH = 240; 
const WINGDIBHEIGHT = 240; 


typedef struct BmInfo 


BITMAPINFOHEADER Header; 
RGBQUAD aColors[256]; 
} BmInfo; 


FTTTLTTTTTTTTTT TTT TTT TATA TAT TL 
FTLTTTTTTTTTT TTT TTT TATA TATA 
// END CUSTOM CODE 

VEAST TTT TATA 
ITTITTTTTTTTTT TTT TTT TTT TTT TAT 


class CAztecView : public CView 


protected: // create from serialization only 
CAztecView() ; 
DECLARE_DYNCREATE (CAztecView) 


// Attributes 
public: 
CAztecDoc* GetDocument() ; 


ILAA ULNIN LAA TTT TTT 
TTTTTTTTTTTTT TTT IIIT 
// START CUSTOM CODE 

TITITTTTITTTT TTT TTT TTT 
VELATIES EEI AA TIITLI AA U EEA A 


protected: 
HBITMAP m_hWinGDib; 
HBITMAP m_hOldBitmap; 
BmInfo m_WinGBmInfo; 
long m_orientation; 
void* m_pWinGDibBits; 
HDC m_hWinGDC; 
HPALETTE m_hPalette; 
CAztecDoc* pDoc; 
CDib* m_pPartsDib; 
UINT m_objects[13]; 
BOOL m_gameOver; 
BOOL m_forwardButtonPressed; 
BOOL m_backButtonPressed; 
BOOL m_leftButtonPressed; 
BOOL m_rightButtonPressed; 
UINT m_nextLevel[10]; 
UINT m_objNums[13]; 
BOOL m_fighting; 
UINT m_monsterNum; 
int m_monsterbHP; 
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[ILILILILIL 
TITTTTTTTTTTTT TTT E EAA ATATA 
// END CUSTOM CODE 

[ILILILILIL IIIT ANA 
[IIIIIII IITIN 


// Operations 
public: 


// Overrides 
// ClassWizard generated virtual function overrides 
//{{AFX_VIRTUAL (CAztecView) 
public: 
virtual void OnDraw(CDC* pDC); // overridden to draw this view 
protected: 
virtual void OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint) ; 
//}}AFX_VIRTUAL 


// Implementation 
public: 
virtual ~CAztecView() ; 
#ifdef _DEBUG 
virtual void AssertValid() const; 
virtual void Dump(CDumpContext& dc) const; 
#endif 


protected: 


TILTTTTTTTTTT TTT TTT TATA AAT TTT 
TITTTTTTTTTTTT TTT TTT TTT TATA TT 
// START CUSTOM CODE 

FINIA EEI ETERA TI EEA I IAEI 
LIILIA EAT I ELEA 


void SetUpWinGStuff () ; 

void DeleteWinGStuf fF () ; 

void CreateIdentityPalette() ; 

void CreateIdentityPalette 
(BmInfo* winGBmInfo, CDib* pDib) ; 

void CopyDIBToWinG (BYTE* m_pWinGDibBits, 
UINT dstX, UINT dstY, CDib* pDib, 
UINT frmX, UINT frmY, UINT frmW, UINT frmH); 

void CalcView(BOOL toggleBMP) ; 

void DrawView() ; 

void CalcNorthView(int* blocks) ; 

void CalcEastView(int* blocks); 

void CalcSouthView(int* blocks) ; 

void CalcWestView(int* blocks) ; 

void InitNewGame(); 

void ShowScene() ; 

void TurnRight(); 

void TurnLeft(); 

BOOL MoveForward(); 

BOOL MoveBack(); 

void DoMove() ; 

void DisplayCompass(CDC* pDC) ; 
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Listing C.5 Continued 


void HandleForwardButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void HandleBackButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void HandleLeftButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void HandleRightButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void DoForwardButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void DoBackwardButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void DoLeftButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void DoRightButton(CClientDC& clientDC, 
BITMAPINFO* pBmInfo) ; 

void CopyDIBToWinGTrns(BYTE* m_pWinGDibBits, 
UINT dstX, UINT dstY, CDib* pDib, UINT frmX, 
UINT frmY, UINT frmW, UINT frmH, UINT trnsColor) ; 

void ShowDoor(UINT objectNum) ; 

void ShowTreasure(UINT objectNum) ; 

void GetKey(UINT number) ; 

void GetPotion(UINT value) ; 

void GetSword(UINT value) ; 

void GetArmor(UINT value) ; 

void GetTreasure(UINT value) ; 

void ShowMessage(UINT type) ; 

void DisplayKeys() ; 

void DisplayPotions(); 

void DisplayBody() ; 

void DisplaySword(CClientDC* pClientDC) ; 

void DisplayArmor(CClientDC* pClientDC) ; 

void OpenDoor(); 

void DisplayStats() ; 

void UpdateExper(int exp); 

void CheckLevel(); 

void ShowMonster(UINT squareNum) ; 

CDib* GetMonsterDib(UINT monsterNum) ; 

void FightMonster() ; 

void DoNextMonsterFrame(UINT num) ; 

void KillMonster(CClientDC* pClientDC) ; 

void StartNextFloor(); 

void HandlePotions(); 

void PlayerDead(); 

void PlayerWins(); 

void ShowScore() ; 


ITTTITLTTTTTTTT ATTA ATTA 
TTTLTITTTTTTTT TTT TTA TTT ATL 
// END CUSTOM CODE 

[ILILILILIL 
[ILILILILIL 
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// Generated message map functions 

protected: 
//{{AFX_MSG(CAztecView) 
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct) ; 
afx_msg void OnDestroy() ; 
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags); 
afx_msg void OnLButtonDown(UINT nFlags, CPoint point) ; 
afx_msg void OnLButtonUp(UINT nFlags, CPoint point); 
afx_msg void OnTimer(UINT nIDEvent) ; 
//}}AFX_MSG 
DECLARE_MESSAGE_MAP( ) 

}; 


#ifndef _DEBUG // debug version in aztecvw.cpp 
inline CAztecDoc* CAztecView: :GetDocument() 

{ return (CAztecDoc*)m_pDocument; } 
#endif 


[ILILILILIL 


Listing C.6 AZTECVW.CPP—Implementation File for the 


CAztecView Class 


// aztecvw.cpp : implementation of the CAztecView class 
// 


#include "stdafx.h" 
#include "“aztec.h" 


#include “aztecdoc.h" 
#include "“aztecvw.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED_CODE THIS FILE[] = _ _FILE__; 
#endif 


[I/III I IIIT 
[IIIIIII III TTT TTT ATTA AA AT 
// START CUSTOM CODE 

(IIUI CEN LIATI TATA TTT 
[IIIILII III TTT TTT TATA TTT 


#include <mmsystem.h> 


[ILILILILIL III TTT TTT TTT ATA TT 
TTLTTTTTTTTTTT TTT TTT TTT AA TT 
// END CUSTOM CODE 

[ILILILILIL 
[ILILILILIL IIIA 


PITIS TANILIAIN IAAL LIANAN ALLAT ELATI d 
// CAztecView 


(continues) 
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Listing C.6 Continued 


IMPLEMENT_DYNCREATE(CAztecView, CView) 


BEGIN _MESSAGE_MAP(CAztecView, CView) 
//{{AFX_MSG_MAP (CAztecView) 
ON_WM_CREATE() 

ON_WM_DESTROY() 
ON_WM_KEYDOWN() 
ON_WM_LBUTTONDOWN ( ) 
ON_WM_LBUTTONUP( ) 
ON_WM_TIMER() 
//}}AFX_MSG_MAP 
END_MESSAGE_MAP() 


TLLTTTTITITTTT AA IAAI NAAALALA EAA AAT AA Ai 
// CAztecView construction/destruction 


CAztecView: :CAztecView( ) 


{ 
// TODO: add construction code here 
} 
CAztecView: :~CAztecView( ) 
{ 
} 


TITLTTTTTTITTAT TTT TTT AT TTT TTT TTT TTT ATTA TTT ATA A 
// CAztecView drawing 


void CAztecView: :OnDraw(CDC* pDC) 

{ 
CAztecDoc* pDoc = GetDocument() ; 
ASSERT_VALID(pDoc) ; 


// TODO: add draw code for native data here 


VINTATA A EE 
TLTTTTTTTTTTTT TTT TTT ATTA TTL 
// START CUSTOM CODE 

COLUERUNT TEET 
LIILIA 


SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 
RealizePalette(pDC->m_hDC); 


// Copy the background image to the WinG bitmap. 
//CopyDIBToWinG( (BYTE*)m_pWinGDibBits, @, ©, 
// pDoc->m_pPartsADib, 0, @, 240, 240); 


// Get a pointer to the panel bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pDibInfo = 

pDoc ->m_pPanelDib->GetDibInfoPtr() ; 
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// Blit the panel onto the window. 
StretchDIBits(pDC->m_hDC, 0, ©, 540, 420, 
@, ©, 540, 420, pDoc->m_pPanelBits, pDibInfo, 
DIB_RGB_COLORS, SRCCOPY) ; 


DisplayCompass(pDC) ; 
DisplayBody() ; 
DisplayKeys(); 
DisplayPotions(); 
DisplayStats(); 


WinGBitBlt(pDC->m_hDC, 51, 51, 
WINGDIBWIDTH, WINGDIBHEIGHT, m_hWinGDC, ©, 0); 


TILTTTTTTTTTTT EITIC ATTA TTT 

[ILILILILIL 

// END CUSTOM CODE 

FITTTTTTTTTTTT TTT TITEL EETA TETINE 

TILTITTTTTTTTT TTT TTA TTT TAT 
} 


PIATEII IIIA NAN CINIA TTT TTA A AAA 
// CAztecView diagnostics 


#ifdef _DEBUG 
void CAztecView: :AssertValid() const 


{ 
CView: :AssertValid(); 
} 
void CAztecView: :Dump(CDumpContext& dc) const 
{ 
CView: :Dump(dc) ; 
} 


CAztecDoc* CAztecView::GetDocument() // non-debug version is inline 


ASSERT (m_pDocument ->IsKindOf (RUNTIME_CLASS(CAztecDoc) )); 
return (CAztecDoc*)m_pDocument; 


} 
#endif //_DEBUG 


TLTLTTTTITTTTT TTT TTT AAA AAA A AA AA AAT AAA 
// CAztecView message handlers 


int CAztecView: :OnCreate(LPCREATESTRUCT lpCreateStruct) 


if (CView::OnCreate(lpCreateStruct) == -1) 
return -1; 


// TODO: Add your specialized creation code here 
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Listing 4.6 Continued 


[IILI II IINITAN 
[LIILIA IIIT 
// START CUSTOM CODE 

[IIIIIIII II IIIN 
FITTTTTTTTTTTT TTT TTT TTT TATA TA 


pDoc = GetDocument() ; 
SetUpWinGStuf Ff () ; 
m_forwardButtonPressed = FALSE; 
m_backButtonPressed = FALSE; 
m_leftButtonPressed = FALSE; 
m_rightButtonPressed = FALSE; 


m_nextLevel[0] = 100; 
m_nextLevel[1] = 200; 
m_nextLevel[2] = 400; 
m_nextLevel[3] = 800; 
m_nextLevel[4] = 1500; 
m_nextLevel[5] = 3000; 
m_nextLevel[6] = 6000; 
m_nextLevel[7] = 12000; 
m_nextLevel[8] = 24000; 
m_nextLevel[9] = 50000; 


// Seed the random-number generator. 
srand( (unsigned) time(Q) ) ; 


// Change window class to disallow double-clicks. 
SetClassLong(m_hWnd, GCL_STYLE, 
CS_HREDRAW ! CS_VREDRAW) ; 


TITTTTTTTTTTTT TTT TTT TATA AT 
[ILILILILIL 
// END CUSTOM CODE 

[LIIIN III IIIA 
PANAIA NAAA ATE EA EAA 


return Q; 


} 


void CAztecView: :OnDestroy() 


{ 
CView: :OnDestroy(); 


// TODO: Add your message handler code here 


PIALI ALITALIA CETINI CANTINA AITE 
FLITTLTTTTTTTT TTT TTT ATL 
// START CUSTOM CODE 

[LIILIA IIIA 
LIIATI TTT TAA TTL 


if (m_hWinGDC) 
DeleteWinGStuf f () ; 


} 
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KillTimer (1); 


FTTTTTTTTTT TTT TATA A ATL 
[ILILILILIL 
// END CUSTOM CODE 

CIUIL NAIL EAEE 
[IIIIIIIII II IIIA 


[ILII IIIA TTT TATA TTL 
VIILAT TATA ATT 
// START CUSTOM CODE 

[ILILILILIL 
[IIIIII II IIIT 


void CAztecView::SetUpWinGStuff() 


{ 


} 


// Get recommended format for the WinG bitmap. 
WinGRecommendDIBFormat 
((BITMAPINFO far *)&m_WinGBmInfo) ; 


// Save the suggested bitmap orientation. 
m_orientation = m_WinGBmInfo.Header.biHeight; 


// Set up the BITMAPINFO structure. 
m_WinGBmInfo.Header.biBitCount = 8; 
m_WinGBmInfo.Header.biCompression = BI_RGB; 
m_WinGBmInfo.Header.biWidth = WINGDIBWIDTH; 
m_WinGBmInfo.Header.biHeight = 
WINGDIBHEIGHT * m_orientation; 


// Create the identity palette. 
//CreateIdentityPalette() ; 
CreateIdentityPalette(&m_WinGBmInfo, pDoc->m_pPartsADib) ; 


// Create the WinG device context. 
m_hWinGDC = WinGCreateDC() ; 


// Create the WinG bitmap and select it into the WinG DC. 
m_hWinGDib = WinGCreateBitmap(m_hWinGDC, 

(BITMAPINFO far *)&m_WinGBmInfo, &m_pWinGDibBits) ; 
m_hOldBitmap = 

(HBITMAP)SelectObject(m_hWinGDC, m_hWinGDib) ; 


// Fill the WinG bitmap with blackness. 
PatBlt(m_hWinGDC, 2Q, 0, 
WINGDIBWIDTH, WINGDIBHEIGHT, BLACKNESS) ; 


void CAztecView: :DeleteWinGStuf fF () 


{ 


// Release the WinG bitmap by selecting the 
// old bitmap back into the WinG DC. 
HBITMAP hBitmap = 
(HBITMAP) SelectObject(m_hWinGDC, m_hOldBitmap) ; 


(continues) 


479 


480 Appendix C—Aztec Adventure Complete Listings 


Listing C.6 Continued 


// Delete the WinG bitmap, DC, and palette. 
DeleteObject(hBitmap) ; 
DeleteDC(m_hWinGDC) ; 
DeleteObject(m_hPalette) ; 

} 


void CAztecView: :CreateIdentityPalette() 

{ 
// Define a structure for the logical palette. 
struct 


WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256] ; 

} logicalPalette = { 0x300, 256 }; 


// Get a device context for the screen. 
HDC hScreenDC = ::GetDC(Q); 


// Load the system palette into the 
// logical palette structure. 
GetSystemPaletteEntries 

(hScreenDC, ©, 256, logicalPalette.aEntries) ; 


// Get rid of the screen DC. 
::ReleaseDC(®, hScreenDC) ; 


// Copy the system colors into the WinG bitmap's 
// color table and set the appropriate flags. 
for(int i = Oji < 256;it++) 
{ 
m_WinGBmInfo.aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed; 
m_WinGBmInfo.aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen; 
m_WinGBmInfo.aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue; 
m_WinGBmInfo.aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = Q; 
} 


// Create the program's logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*)&logicalPalette) ; 
} 


void CAztecView: :CreateIdentityPalette 
(BmInfo* winGBmInfo, CDib* pDib) 


{ 
struct 


WORD Version; 

WORD NumberOfEntries; 

PALETTEENTRY aEntries[256] ; 
} logicalPalette = {0x300, 256}; 
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// Get the screen DC. 
HDC Screen = ::GetDC(Q); 


// Copy Windows' 20 standard system colors 
// into the new logical palette. 
GetSystemPaletteEntries 

(Screen, ©, 10, logicalPalette.aEntries) ; 
GetSystemPaletteEntries 

(Screen, 246, 10, logicalPalette.aEntries + 246); 


// Get rid of the screen DC. 
::ReleaseDC(@,Screen) ; 


// Copy the standard 20 system colors into 
// the WinG bitmap's color table. 
for(int i = 0; i < 10; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i] .peBlue; 
winGBmInfo->aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = 0; 


winGBmInfo->aColors[i + 246].rgbRed = 
logicalPalette.aEntries[i + 246].peRed; 
winGBmInfo->aColors[i + 246].rgbGreen = 
logicalPalette.aEntries[i + 246].peGreen; 
winGBmInfo->aColors[i + 246].rgbBlue = 
logicalPalette.aEntries[i + 246] .peBlue; 
winGBmInfo->aColors[i + 246].rgbReserved = 0; 


logicalPalette.aEntries[i + 246].peFlags = 0; 
} 


// Get a pointer to the source bitmap's color table. 
LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr() ; 


// Copy the source bitmap's color table into both 
// the WinG bitmap color table and 
// into the new logical palette. 
for(i = 10; i < 246; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed = 
pColorTable[i].rgbRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen = 
pColorTable[i].rgbGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i].rgbBlue; 
winGBmInfo->aColors[i].rgbReserved = Q; 
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Listing C.6 Continued 


logicalPalette.aEntries[i].peFlags = 
PC_NOCOLLAPSE ; 
} 


// Create the logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*)&logicalPalette) ; 


} 


void CAztecView: :CopyDIBToWinG 
(BYTE* m_pWinGDibBits, UINT dstX, UINT dstyY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frmH) 


{ 
// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight() ; 
// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr() ; 
// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=0; col<frmW; ++col) 
{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcy * srcWidth + col + frmX; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstX; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex]; 
} 
} 


IPULI LITEA AT CATET 
TIITITTTTTTTTTT TTT TTT TTT AL 
// END CUSTOM CODE 

TIALLE EAA AN TA UII TT 
VAALIA AANE CLAIE 


void CAztecView: :OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint) 


{ 
// TODO: Add your specialized code here and/or call the base class 


[ILILILILIL 
TIITTTTTTTTTTT TTT TTT TTT 
// START CUSTOM CODE 

FITTTTTTTTTTTTT TTT TATA TL 
TAFLA LEENI TTT ATT 


} 
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// Initialize the view's game variables. 
InitNewGame() ; 


// Reinitialize the WinG DC, bitmap, 
// and identity palette. 
DeleteWinGStuff () ; 

SetUpWinGStuf f () ; 


// Set the pointer to the bitmap containing 
// the wall and door objects. 
m_pPartsDib = pDoc->m_pPartsADib; 


// Set up the identity palette. 

CClientDC clientDC(this) ; 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Build the 3-D view and copy it to the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 


// Force the main window to redraw. 
Invalidate (FALSE); 


JILLIAN TINTAN AA TATA TTA TTT TL 
FTTLTTTTTT ATIII TTA TATA ATL 
// END CUSTOM CODE 

[I/III TTT TATA TAT TTL 
FITTTTTTTTT ATT TTT TTT ATA TATA ATT 


[ILILILILIL TTT ATT TTT ATTA ATTA TAT 
FITTTTTTTTTT TATA ATTA ATT 
// START CUSTOM CODE 

FITTTTTTTTTTT TTT 
FITTTTTTTTTTT TTT TATA TAAL 


void CAztecView: :CalcView(BOOL toggleBMP) 


{ 


// Return immediately if the game is over. 
if (m_gameOver) 
return; 


int blockNums[13]; 


// Get the numbers of the visible squares. 
switch (pDoc->m_faceDir) 


{ 
case North: CalcNorthView(blockNums) ; break; 
case West: CalcWestView(blockNums); break; 
case South: CalcSouthView(blockNums) ; break; 
case East: CalcEastView(blockNums); break; 

} 


// Store the object types for the 13 visible 
// squares in the m_objects[] array. 
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Listing C.6 Continued 


for (int i=0; i<13; ++i) 


} 


{ 


} 
// 


// If the square is off the grid, set it to empty. 
if ((blockNums[i] < @) |; 
(blockNums[i] > DUNGEONSIZE -1) ) 
m_objects[i] = Empty; 
else 
{ 
// Get a pointer to the item for the square. 
CItem* item = 
(CItem*) pDoc->m_Dungeon.GetAt (blockNums[i]) ; 


// Store the item's type in the object array. 
m_objects[i] = item->iType; 


// Store the item's number. 
m_objNums[i] = item->iNumber; 


If requested, switch between dungeon images. 


if (toggleBMP) 


if (m_pPartsDib == pDoc->m_pPartsADib) 
m_pPartsDib = pDoc->m_pPartsBDib; 
else 
m_pPartsDib = pDoc->m_pPartsADib; 


void CAztecView: :CalcNorthView(int* blocks) 


{ 


} 


// Calculate the visible blocks when the 


// 


blocks[0] = (pDoc->m_playeryY-3) * 
blocks[1] = (pDoc->m_playeryY-3) * 
blocks[2] = (pDoc->m_playerY-3) * 
blocks[3] = (pDoc->m_playeryY-3) * 
blocks[4] = (pDoc->m_playerY-3) * ROWSIZE 
blocks[5] = (pDoc->m_playerY-2) * 
blocks[6] = (pDoc->m_playeryY-2) * 
blocks[7] = (pDoc->m_playeryY-2) * 
blocks[8] = (pDoc->m_playerY-1) * 
blocks[9] = (pDoc->m_playeryY-1) * 


player is facing north. 

ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 


+ pDoc->m_playerX - 2; 
+ pDoc->m_playerX + 2; 
+ pDoc->m_playerxX - 1; 
+ pDoc->m_playerX + 1; 
+ pDoc->m_playerx; 

ROWSIZE + pDoc->m_playerx - 1; 
ROWSIZE + pDoc->m_playerX + 1; 
ROWSIZE + pDoc->m_playerXx; 

ROWSIZE + pDoc->m_playerXx - 1; 
ROWSIZE + pDoc->m_playerX + 1; 


blocks[10] = (pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx; 


blocks[11] 


pDoc->m_playerY * ROWSIZE + pDoc->m_playerx - 1; 


blocks[12] = pDoc->m_playerY * ROWSIZE + pDoc->m_playerx + 1; 


void CAztecView: :CalcEastView(int* blocks) 


// Calculate the visible blocks when the 
// player is facing east. 
blocks[®] = (pDoc->m_playerY-2) * ROWSIZE + pDoc->m_playerx+3; 


blocks[1] 
blocks[2] 
blocks[3] 
blocks[4] 
blocks[5] 
blocks[6] 
blocks[7] 
blocks[8] 
blocks[9] 
blocks[10] 
blocks[11] 
blocks[12] 
} 


(pDoc->m_playerY+2) * ROWSIZE + pDoc->m_playerXx+3; 
(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx+3; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx+3; 
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(pDoc->m_playerY) * ROWSIZE + pDoc->m_playerX+3; 


(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx+2; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx+2; 


pDoc->m_playerY * ROWSIZE + pDoc->m_playerxX+2; 


(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerXx+1; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerXx+1; 
pDoc->m_playerY * ROWSIZE + pDoc->m_playerxX+1; 

(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx; 
(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx; 


void CAztecView: :CalcSouthView(int* blocks) 


{ 


// Calculate the visible blocks 


// player 
blocks[@] 
blocks[1] 
blocks[2] 
blocks[3] 
blocks[4] 
blocks[5] 
blocks[6] 
blocks[7] 
blocks[8] 
blocks[9] 
blocks[10] 
blocks[11] 
blocks[12] 


} 


a 


s facing south. 
(pDoc ->m_playerY+3) 
(pDoc ->m_playerY+3) 
(pDoc ->m_playerY+3) 
(pDoc ->m_playerY+3) 
(pDoc ->m_playerY+3) 
(pDoc ->m_playerY+2) 
(pDoc ->m_playerY+2) 
(pDoc ->m_playerY+2) 
(pDoc ->m_playerY+t1 ) 
(pDoc ->m_playerY+1) 


when the 


+ + FF FF FF FF FH FF FF 


ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 


void CAztecView: :CalcWestView(int* blocks) 


{ 


// Calculate the visible blocks when the 
is facing west. 


// player 
blocks[Q] 
blocks[1] 
blocks[2] 
blocks[3] 
blocks[4] 
blocks[5] 
blocks[6] 
blocks[7] 
blocks[8] 
blocks[9] 
blocks[10] 
blocks[11] 
blocks[12] 


} 


void CAztecView 


{ 


// Return immediately if the game is over. 


(pDoc ->m_playerY+2) 
(pDoc ->m_playeryY -2) 
(pDoc ->m_playerY+1 ) 
(pDoc ->m_playerY-1) 
(pDoc->m_playeryY) * 


(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerx-2; 
(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerXx-2; 


* 
* 
* 


* 


ROWSIZE 
ROWSIZE 
ROWSIZE 
ROWSIZE 


ROWSIZE + 


+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 


+ 
+ 
+ 


+ 


pDoc ->m_playerXx 
pDoc ->m_playerx 
pDoc ->m_playerXx 
pDoc ->m_playerXx 
pDoc->m_playerx; 
pDoc ->m_playerx 
pDoc ->m_playerx 
pDoc ->m_playerXx; 
pDoc ->m_playerx 
pDoc ->m_playerx 


pDoc ->m_playerXx-3; 
pDoc ->m_playerXx-3; 
pDoc->m_playerXx-3; 
pDoc ->m_playerXx-3; 


pDoc->m_playerXx-3; 


pDoc->m_playerY * ROWSIZE + pDoc->m_playerXx-2; 


(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerX-1; 
(pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerxX-1; 


= pDoc->m_playerY * ROWSIZE + pDoc->m_playerXx-1; 


+ 


+ 


(pDoc->m_playerYt+1) * ROWSIZE + pDoc->m_playerx; 
= pDoc->m_playerY * ROWSIZE + pDoc->m_playerxX + 1; 
= pDoc->m_playerY * ROWSIZE + pDoc->m_playerx - 1; 


(pDoc->m_playerY+1) * ROWSIZE + pDoc->m_playerXx; 


= (pDoc->m_playerY-1) * ROWSIZE + pDoc->m_playerx; 


::DrawView() 


if (m_gameOver) 


return; 
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Listing C.6 Continued 


// Define coordinates for each of the 13 
// possible wall objects. 
UINT wallcoords[13][6] = 
{ 
0, 83, 242, 0, 31, 74, 
209, 83, 513, ©, 31, 74, 
9, 83, 274, 0, 81, 74, 
149, 83, 431, ©, 81, 74, 
83, 83, 356, @, 74, 74, 
@, 68, 242, 87, 84, 104, 
156, 68, 432, 87, 84, 104, 
68, 68, 327, 87, 104, 104, 
@, 30, ©, 241, 69, 180, 
171, 30, 249, 241, 69, 180, 
30, 30, 70, 241, 178, 180, 
©, ©, 572, 146, 31, 240, 
209, ©, 604, 146, 31, 240 
}; 


// Get a pointer to the source bitmap's 

// BITMAPINFO structure. 

LPBITMAPINFO pBmInfo = 
m_pPartsDib->GetDibInfoPtr() ; 


// Copy the background scene to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 0, 0, 
m_pPartsDib, ®©, ©, 240, 240); 


// Check all 13 visible squares for objects. 
for (int i=0; i<13; ++i) 
{ 

// If the current square is a wall... 

if (m_objects[i] == Wall) 


// Copy the wall's image from the source 
// bitmap to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
wallcoords[i][®], wallcoords[i][1], 
m_pPartsDib, 
wallcoords[i][2], wallcoords[i][3], 
wallcoords[i][4], wallcoords[i][5]); 


else if (m_objects[i] == Door) 
ShowDoor (i) ; 

else if (m_objects[i] == Treasure) 
ShowTreasure(i); 

else if (m_objects[i] == Potion) 
ShowTreasure (i); 

else if (m_objects[i] == Sword) 
ShowTreasure(i) ; 

else if (m_objects[i] == Armor) 


ShowTreasure(i); 
else if (m_objects[i] == Key) 
ShowTreasure(i) ; 
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else if (m_objects[i] == Monster) 
ShowMonster (i) ; 
} 


// If the player is on level 1, show the 
// appropriate horizon scene. 
if (pDoc->m_floorNum == 1) 

ShowScene(); 


} 
void CAztecView: :ShowScene() 
{ 
UINT x, y; 
// Get the appropriate scene's coordinates 
// in the source bitmap. 
switch (pDoc->m_faceDir) 
{ 
case North: x = 454; y = 192; break; 
case East: x = 454; y = 276; break; 
case South: x = 454; y = 360; break; 
case West: x = 341; y = 360; break; 
} 
// Copy the horizon scene to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
64, @, m_pPartsDib, x, y, 112, 83); 
} 
void CAztecView: : InitNewGame() 
{ 
// Initialize the game-over flag. 
m_gameOver = FALSE; 
// Initialize the fighting flag. 
m_fighting = FALSE; 
} 


AIII ILNI TEATATI TTT TATA TT 
[ILILILILIL 
// END CUSTOM CODE 

LEILA 
CIIILE AAA ECT 


void CAztecView: :OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags) 


{ 
// TODO: Add your message handler code here and/or call default 


PECICA IEAA AAI ANTI AATA TEE A 
IITIN N ANAL INI ANANA ATIATI AATA 
// START CUSTOM CODE 

[ILILILILIL ITALA 
FUTTITTTTTTTT TTT TTA TTT TTT TTT 


// If the game is over, return immediately. 
//if (m_gameOver) 
// return; 
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Listing C.6 Continued 


// If the player is fighting a monster or 
// the game is over, return immediately. 
if (m_fighting |; m_gameOver) 

return; 


// Initialize the Boolean flag. 
BOOL moveOK = TRUE; 


// Perform the appropriate move based on the 
// key pressed. This function responds only to 
// the arrow keys. 
switch(nChar) 
{ 
case VK_LEFT: TurnLeft(); break; 
case VK_RIGHT: TurnRight(); break; 
case VK_UP: moveOK = MoveForward(); break; 
case VK_DOWN: moveOK = MoveBack(); break; 
default: moveOK = FALSE; 
} 


// If the requested move checks out okay, do it. 
if (moveOK) 
DoMove() ; 


[IIIIIIIIII TTT TTT TTT TTA TTA 
[IILI III TTT TTT TTT TTA TAAL 
// END CUSTOM CODE 

[ILILILILIL 
[ILILILILIL IILI 


CView: :OnKeyDown(nChar, nRepCnt, nFlags); 
} 


FITILIN AEAEE CETA 
[IILI III II IIIA 
// START CUSTOM CODE 

CLEIGEN AN EAA TTT AAAA EA EE. 
[IILI III IAIA 


void CAztecView::TurnLeft() 


// Update the player's facing direction. 
switch(pDoc ->m_faceDir) 


{ 
case North: pDoc->m_faceDir = West; break; 
case East : pDoc->m_faceDir = North; break; 
case South: pDoc->m_faceDir = East; break; 
case West : pDoc->m_faceDir = South; break; 
} 


} 


void CAztecView: :TurnRight () 
{ 


} 


/* 
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// Update the player's facing direction. 
switch (pDoc->m_faceDir) 


{ 
case North: pDoc->m_faceDir = East; break; 
case East : pDoc->m_faceDir = South; break; 
case South: pDoc->m_faceDir = West; break; 
case West : pDoc->m_faceDir = North; break; 
} 


BOOL CAztecView: :MoveForward() 


{ 


} 


*/ 


// Save the player's current position. 
UINT oldX = pDoc->m_playerx; 
UINT oldY = pDoc->m_playeryY; 


// Update the player's position based on 
// which direction he's facing. 
switch(pDoc->m_faceDir) 


{ 
case North: --pDoc->m_playerY; break; 
case East : ++pDoc->m_playerX; break; 
case South: ++pDoc->m_playerY; break; 
case West : --pDoc->m_playerX; break; 
} 


// Calculate the number of the square that 
// the player is about to move onto. 
UINT square = pDoc->m_playerY * ROWSIZE + pDoc->m_playerx; 


// Get the item stored in that square. 
CItem* item = (CItem*)pDoc->m_Dungeon.GetAt (square); 


// If the item is a wall, the player can't move there. 
if (item->iType == Wall) 


{ 
// Restore old player position. 
pDoc->m_playerxX = oldX; 
pDoc->m_playerY = oldyY; 
// Indicate that the move failed. 
return FALSE; 

} 


// Indicate that the move is okay. 
return TRUE; 


BOOL CAztecView: :MoveForward() 


{ 


// Initialize temporary variables for the 
// player's new position. 

UINT newX = pDoc->m_playerx; 

UINT newY = pDoc->m_playerY; 
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Listing C.6 Continued 


// Update the player's position based on 
// which direction he's facing. 
switch(pDoc ->m_faceDir) 


{ 
case North: newY = pDoc->m_playerY - 1; break; 
case East : newX = pDoc->m_playerX + 1; break; 
case South: newY = pDoc->m_playerY + 1; break; 
case West : newX = pDoc->m_playerX - 1; break; 
} 


// Calculate the number of the square that 
// the player is about to move onto. 
UINT square = newY * ROWSIZE + newX; 


// Get the item stored in that square. 
CItem* pItem = (CItem*)pDoc->m_Dungeon.GetAt (square); 


// If the item is a wall, the player can't move there. 
if (pItem->iType == Wall) 

return FALSE; 
else if (pItem->iType == Key) 


{ 
pItem->iType = Empty; 
GetKey(pItem->iNumber) ; 
return FALSE; 

} 

else if (pItem->iType == Potion) 

{ 
pItem->iType = Empty; 
GetPotion(pItem->iValue) ; 
return FALSE; 

} 

else if (pItem->iType == Sword) 

{ 
pItem->iType = Empty; 
GetSword(pItem->iValue) ; 
return FALSE; 

} 

else if (pItem->iType == Armor) 

{ 
pItem->iType = Empty; 
GetArmor (pItem->iValue) ; 
return FALSE; 

} 

else if (pItem->iType == Treasure) 

{ 


pItem->iType = Empty; 
GetTreasure(pItem->iValue) ; 
return FALSE; 


else if (pItem->iType == Door) 
{ 
if (pDoc->m_keys[pItem->iNumber ] ) 


}; 
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pItem->iType = Empty; 
OpenDoor(); 


} 
return FALSE; 


else if (pItem->iType == Monster) 


{ 
pItem->iType = Empty; 
m_fighting = TRUE; 
m_monsterNum = pItem->iNumber; 
m_monsterHP = pItem->iValue; 
FightMonster() ; 
return FALSE; 

} 


// Set the player's new position in the dungeon. 
pDoc->m_playerX = newX; 
pDoc->m_playerY = newY; 


// Indicate that the move is okay. 
return TRUE; 


BOOL CAztecView: :MoveBack() 


{ 


// Save the player's current position. 
UINT oldX = pDoc->m_playerx; 
UINT oldY = pDoc->m_playeryY; 


// Update the player's position based on 
// which direction he's facing. 
switch(pDoc->m_faceDir) 


{ 
case North: ++pDoc->m_playerY; break; 
case East : --pDoc->m_playerX; break; 
case South: --pDoc->m_playerY; break; 
case West : ++pDoc->m_playerX; break; 
} 


// Calculate the number of the square that 
// the player is about to move onto. 
UINT square = pDoc->m_playerY * ROWSIZE + pDoc->m_playerx; 


// Get the item stored in that square. 
CItem* item = (CItem*)pDoc->m_Dungeon.GetAt (square); 


// If the square isn't empty, 

// the player can't move there. 

if (item->iType != Empty) 

{ 
// Restore the player's old position. 
pDoc ->m_playerxX = oldX; 
pDoc->m_playerY = oldyY; 
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Listing C.6 Continued 


// Tell the calling function that the move failed. 
return FALSE; 
} 


// Tell the calling function that the move is okay. 
return TRUE; 


} 


void CAztecView: :DoMove() 

{ 
// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Get a pointer to the source 

// bitmap's BITMAPINFO structure. 

LPBITMAPINFO pBmInfo = 
m_pPartsDib ->GetDibInfoPtr() ; 


// Calculate the new view and draw the 
// view on the WinG bitmap. 
CalcView(TRUE) ; 

DrawView() ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Blit the WinG bitmap to the window. 
WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, ©, 0); 


// Play the footstep sound effect. 
sndPlaySound("FOOTSTEP.WAV", SND_SYNC ; SND_NODEFAULT) ; 


// Update the compass face. 
DisplayCompass (&clientDC) ; 
} 


FITILTLTT TTT TTT TTT TTT ATA TL 
[ILILILILIL 
// END CUSTOM CODE 

[IIIIIILIIII TTT TTT TATA TAA TTT 
FITTITLTTTTT TTT TTT ATTA TATA AAT 


void CAztecView: :OnLButtonDown(UINT nFlags, CPoint point) 


{ 
// TODO: Add your message handler code here and/or call default 


CELAA IAAI IA IA ACTII CEIA 
[IIIIIII II IIINE 
// START CUSTOM CODE 

[ILILILILIL IIIA IIINE 
[IILIIII IIIA IIIA 
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// If the game is over, return immediately. 
// if (m_gameOver) 
// return; 


// If the player is fighting a monster or 
// the game is over, return immediately. 
if (m_fighting |; m_gameOver) 

return; 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// Clicked on forward button? 
if ((point.x > 184) && (point.x < 234) && 
(point.y > 296) && (point.y < 330)) 
HandleForwardButton(clientDC, pBmInfo); 


// Clicked on backward button? 
else if ((point.x > 184) && (point.x < 234) && 
(point.y > 336) && (point.y < 368)) 
HandleBackButton(clientDC, pBmInfo); 


// Clicked on left button? 
else if ((point.x > 128) && (point.x < 178) && 
(point.y > 296) && (point.y < 368)) 
HandleLeftButton(clientDC, pBmInfo); 


// Clicked on right button? 
else if ((point.x > 240) && (point.x < 290) && 
(point.y > 298) && (point.y < 368)) 
HandleRightButton(clientDC, pBmInfo) ; 


// Clicked on the potions? 
else if ((point.x > 312) && (point.x < 502) && 
(point.y >351) && (point.y < 384) && 
(pDoc->m_potionCount > @)) 
HandlePotions(); 


TTLTTTTTTTTTTTTT TATA TTT TATA 
[IIIN TTT TTT TTT TTT TATA 
// END CUSTOM CODE 

[IITTI TTT TTT TTT TTT ATT 
FITTTTTTTTTT TTT TTT TTT TAA AT 
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Listing C.6 Continued 


CView: :OnLButtonDown(nFlags, point) ; 
} 


void CAztecView: :OnLButtonUp(UINT nFlags, CPoint point) 


{ 
// TODO: Add your message handler code here and/or call default 


FITTTTTTTTTT TTT TATA TTT TTT 
[I/III IIIA 
// START CUSTOM CODE 

FITTTTTTTTTT TATA TATA TATA ATT TT 
[IIIIIIIIIII TTT TTT TATA TAA ATT 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source 
// bitmap's BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib->GetDibInfoPtr() ; 


// If the forward button is depressed... 
if (m_forwardButtonPressed) 
DoForwardButton(clientDC, pBmInfo) ; 


// ...else if the backward button is depressed... 
else if (m_backButtonPressed) 
DoBackwardButton(clientDC, pBmInfo) ; 


// ...else if the left button is depressed... 
else if (m_leftButtonPressed) 
DoLeftButton(clientDC, pBmInfo) ; 


// ...else if the right button is depressed. 
else if (m_rightButtonPressed) 
DoRightButton(clientDC, pBmInfo) ; 


FITTLTTTTTTTT TTT TTT TTT ATA 
FLLTTTTTTT TTT TTT TTT TTT ATTA TT 
// END CUSTOM CODE 

LITTTTLTTTT ISAN ECET ALELA 
VESANEN TET TEETE AII EEA 


CView: :OnLButtonUp(nFlags, point); 
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[ILILILILIL 
EISILA AAEE CIAL LEATA 
// START CUSTOM CODE 

ILILILILIL 
FTTTTTTTTTTTT TTT TTT ATTA ATTA 


void CAztecView: :DoForwardButton 


{ 


} 


(CClientDC& clientDC, BITMAPINFO* pBmInfo) 


// Draw the button in its unselected form. 
StretchDIBits(clientDC.m_hDC, 


183, 297, 52, 34, 

108, 182, 52, 34, 

pDoc ->m_pSundryBits, 

pBmInfo, DIB_RGB_COLORS, SRCCOPY); 


// Turn off the button's flag. 
m_forwardButtonPressed = FALSE; 


// Release the mouse capture. 
ReleaseCapture(); 


// Check whether it's okay to move forward. 
BOOL moveOK = MoveForward(); 


// If it is okay, do it. 
if (moveOK) 
DoMove() ; 


void CAztecView: :DoBackwardButton 


{ 


} 


(CClientDC& clientDC, BITMAPINFO* pBmInfo) 


StretchDIBits(clientDC.m_hDC, 


183, 335, 52, 34, 

0, 182, 52, 34, 
pDoc->m_pSundryBits, 

pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


m_backButtonPressed = FALSE; 
ReleaseCapture(); 

BOOL moveOK = MoveBack() ; 

if (moveOK) 


DoMove(); 


void CAztecView: :DoLeftButton 


{ 


(CClientDC& clientDC, BITMAPINFO* pBmInfo) 


StretchDIBits(clientDC.m_hDC, 


127, 297, 52, 72, 

@, 108, 52, 72, 

pDoc ->m_pSundryBits, 

pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


m_leftButtonPressed = FALSE; 
ReleaseCapture(); 
TurnLeft(); 
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Listing C.6 Continued 


DoMove(); 
} 


void CAztecView: :DoRightButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
StretchDIBits(clientDC.m_hDC, 
239, 297, 52, 72, 
108, 108, 52, 72, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
m_rightButtonPressed = FALSE; 
ReleaseCapture() ; 
TurnRight () ; 
DoMove() ; 
} 


void CAztecView: :HandleForwardButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
// Blit the depressed button image to the window. 
StretchDIBits(clientDC.m_hDC, 
183, 297, 52, 34, 
162, 182, 52, 34, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


// Set the button flag. 
m_forwardButtonPressed = TRUE; 


// Capture the mouse. 
SetCapture() ; 
} 


void CAztecView: :HandleBackButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
StretchDIBits(clientDC.m_hDC, 
183, 335, 52, 34, 
54, 182, 52, 34, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
m_backButtonPressed = TRUE; 
SetCapture() ; 
} 


void CAztecView: :HandleLeftButton 
(CClientDC& clientDC, BITMAPINFO* pBmInfo) 
{ 
StretchDIBits(clientDC.m_hDC, 
127; 297; 52, :72', 
54, 108, 52, 72, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


} 
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m_leftButtonPressed = TRUE; 
SetCapture() ; 


void CAztecView: :HandleRightButton 


{ 


} 


(CClientDC& clientDC, BITMAPINFO* pBmInfo) 


StretchDIBits(clientDC.m_hDC, 

239, 297, 52, 72, 

162, 108, 52, 72, 

pDoc->m_pSundryBits, 

pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
m_rightButtonPressed = TRUE; 
SetCapture() ; 


void CAztecView: :DisplayCompass(CDC* pDC) 


{ 


} 


// Get a pointer to the source 
// bitmap's BITMAPINFO structure. 
BITMAPINFO* pDibInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


UINT x; 
// Get the coordinates of the appropriate compass 


// face based on the player's facing direction. 
switch (pDoc->m_faceDir) 


{ 
case North: x = 0; break; 
case West : x = 60; break; 
case South: x = 120; break; 
case East x = 180; 

} 


// Select and realize the palette. 
SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 
RealizePalette(pDC->m_hDC) ; 


// Blit the compass face onto the window. 
StretchDIBits(pDC->m_hDC, 58, 309, 58, 58, 
x, 218, 58, 58, pDoc->m_pSundryBits, pDibInfo, 
DIB_RGB_COLORS, SRCCOPY) ; 


void CAztecView: :ShowDoor(UINT objectNum) 


switch (objectNum) 
{ 
case 0: 
if (m_objects[2] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
0, 88, m_pPartsDib, 
610, 388, 10, 63); 
break; 
case 1: 
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Listing C.6 Continued 


if (m_objects[3] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
230, 88, m_pPartsDib, 
596, 388, 10, 63); 
break; 
case 2: 
if (m_objects[4] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
19, 88, m_pPartsDib, 
574, 388, 66, 63); 
break; 
case 3: 
if (m_objects[4] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
155, 88, m_pPartsDib, 
574, 388, 66, 63); 
break; 
case 4: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
87, 88, m_pPartsDib, 
574, 388, 66, 63); 
break; 
case 5: 
if (m_objects[7] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
0, 78, m_pPartsDib, 
555, 0, 77, 86); 
break; 
case 6: 
if (m_objects[7] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
162, 78, m_pPartsDib, 
545, 0, 77, 86); 
break; 
case 7: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
77, 78, m_pPartsDib, 
545, 0, 86, 86); 
break; 
case 8: 
if (m_objects[10] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
0, 52, m_pPartsDib, 
396, 192, 50, 136); 
break; 
case 9: 
if (m_objects[10] == Wall) 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
189, 52, m_pPartsDib, 
319, 192, 51, 136); 
break; 
case 10: 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
52, 52, m_pPartsDib, 
319, 192, 134, 136); 


} 
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void CAztecView: :ShowTreasure(UINT objectNum) 


{ 


} 


int coords[13][6] = 

{ 
0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 
21, 140, 78, 446, 30, 12, 
185, 140, 78, 446, 30, 12, 
102, 140, 78, 446, 30, 12, 
@, 160, 92, 423, 35, 21, 
204, 160, 78, 423, 35, 21, 
90, 160, 78, 423, 49, 21, 
@, 180, 56, 423, 20, 43, 
220, 180, @, 423, 20, 43, 
82, 180, 0, 423, 76, 43, 
0, ©, ©, 0, 0, 0, 
0, 0, 0, 0, 0, @ 

}; 


CopyDIBTOoWinGTrns ( (BYTE*)m_pWinGDibBits, 
coords[objectNum] [0], 
coords[objectNum] [1], 
m_pPartsDib, 
coords[objectNum] [2], 
coords[objectNum] [3], 
coords[objectNum] [4], 
coords[objectNum] [5], 253); 


void CAztecView: :CopyDIBToWinGTrns 


(BYTE* m_pWinGDibBits, UINT dstX, UINT dstyY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frmH, 
UINT trnsColor) 


// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight(); 


// Get a pointer to the image's data. 
BYTE* pDibBits = pDib->GetDibBitsPtr(); 


// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=0; col<frmW; ++col) 
{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmx; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
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Listing C.6 Continued 


newDstY = row + dstyY; 

DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstX; 

if (pDibBits[srcIndex] != trnsColor) 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 


} 


void CAztecView: :GetKey(UINT number) 


{ 
// Tell the player he found a key. 


ShowMessage (Key); 


// Record the key in the key array. 
pDoc->m_keys[number] = TRUE; 


// Update the key display. 
DisplayKeys() ; 


// Add to player's experience. 
UpdateExper (2) ; 


// Show new statistics. 
DisplayStats(); 
} 


void CAztecView: :GetPotion(UINT value) 
{ 
// Tell the player what he found. 
ShowMessage (Potion) ; 


// If there's room for another potion... 
if (pDoc->m_potionCount < 6) 
{ 
// Increment the potion count. 
++pDoc ->m_potionCount ; 


// Record the potion's value. 
pDoc ->m_potionValues[pDoc->m_potionCount-1] = value; 


} 


// Update the potion display. 
DisplayPotions(); 


// Add to player's experience. 
UpdateExper (2) ; 


// Show new statistics. 
DisplayStats(); 
} 


void CAztecView: :GetSword(UINT value) 
{ 


} 
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// Tell player what he found. 
ShowMessage (Sword) ; 


// Set the sword flag. 
pDoc->m_hasSword = TRUE; 


// Update the player's attack statistic. 
pDoc->m_playerAttack = value; 


// Record the player's new weapon type. 
pDoc->m_curSword = pDoc->m_floorNum - 1; 


// Add to player's experience. 
UpdateExper (2) ; 


// Display new statistics. 
DisplayStats(); 


// Show new body with sword. 
DisplayBody() ; 


void CAztecView: :GetArmor(UINT value) 


{ 


} 


// Tell the player what he found. 
ShowMessage (Armor); 


// Set the shield flag. 
pDoc->m_hasArmor = TRUE; 


// Update the player's defense statistic. 
pDoc->m_playerDefense = value; 


// Record the player's new armor type. 
pDoc->m_curArmor = pDoc->m_floorNum - 1; 


// Add to player's experience. 
UpdateExper (2); 


// Display new statistics. 
DisplayStats(); 


// Show new body with shield. 
DisplayBody() ; 


void CAztecView: :GetTreasure(UINT value) 


{ 


// Tell the player that he found some treasure. 
ShowMessage(Treasure) ; 


// Increase the player's gold. 
pDoc->m_playerGold += value; 


// Add to player's experience. 
UpdateExper (2) ; 
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Listing C.6 Continued 


// Display new statistics. 
DisplayStats() ; 


} 
void CAztecView: :ShowMessage(UINT type) 
{ 
// Get DC for the window. 
CClientDC clientDC(this) ; 
// Select and realize the identity palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 
UINT x, y; 
switch(type) 
{ 
case Treasure: x = Q; y = 0; break; 
case Armor: x = 164; y = @; break; 
case Key: xX = 0; y = 94; break; 
case Potion: x = 164; y = 94; break; 
case Sword: x = 0; y = 188; break; 
} 
// Copy the message to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
10, 10, pDoc->m_pMessageDib, 
x, y, 165, 94); 
// Display the scene. 
WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, 0, 0); 
} 


void CAztecView: :DisplayKeys() 
{ 
// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE) ; 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr () ; 


// Display up to six keys. 

for (UINT i=@; i<6; ++i) 

{ 
// If the player has this key, show it. 
if (pDoc->m_keys[i]) 


} 
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StretchDIBits(clientDC.m_hDC, 
311 + i * 32, 297, 32, 32, 
@, 448 - i * 34, 32, 32, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


void CAztecView: :DisplayPotions() 


{ 


} 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Erase the current potion display. 
clientDC.SelectStock0Obj ect (BLACK_BRUSH) ; 
clientDC.Rectangle(312, 351, 502, 384); 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// Display the player's potions. 
for (UINT i=; i<pDoc->m_potionCount; ++i) 
StretchDIBits(clientDC.m_hDC, 
311 + i * 32, 351, 32, 32, 
102, 380, 32, 32, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


void CAztecView: :DisplayBody () 


{ 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select and realize the palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 

pDoc ->m_pSundryDib->GetDibInfoPtr() ; 


// If the user has no sword or shield, 
// display the normal body. 
if ((!pDoc->m_hasSword) && (!pDoc->m_hasArmor) ) 
StretchDIBits(clientDC.m_hDC, 
392, 52, 48, 87, 
152, 291, 48, 87, 
pDoc->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 
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Listing C.6 Continued 


// Otherwise, display the battle-ready body. 
else 
StretchDIBits(clientDC.m_hDC, 
392, 52, 48, 87, 
102, 291, 48, 87, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


// Display the player's sword and shield. 
DisplaySword(&clientDC) ; 
DisplayArmor (&clientDC) ; 


} 


void CAztecView: :DisplaySword(CClientDC* pClientDC) 
{ 
// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 
pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// If the player has a sword, show it. 
if (pDoc->m_hasSword) 
StretchDIBits(pClientDC->m_hDC, 
381, 46, 27, 93, 
202+ (pDoc ->m_curSword)*29, 285, 27, 93, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_ COLORS, SRCCOPY) ; 
} 


void CAztecView: :DisplayArmor(CClientDC* pClientDC) 
{ 
// Get a pointer to the source bitmap's 
// BITMAPINFO structure. 
BITMAPINFO* pBmInfo = 
pDoc ->m_pSundryDib ->GetDibInfoPtr() ; 


// If the player has a shield, show it. 
if (pDoc->m_hasArmor) 
StretchDIBits(pClientDC->m_hDC, 
421, 68, 32, 32, 
136+ (pDoc->m_curArmor)*34, 448, 32, 32, 
pDoc ->m_pSundryBits, 
pBmInfo, DIB_RGB_COLORS, SRCCOPY) ; 


} 


void CAztecView: :OpenDoor () 


{ 
// Get a DC for the window. 


CClientDC clientDC(this) ; 


// Select and realize the identity palette. 
SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 
RealizePalette(clientDC.m_hDC) ; 


} 
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// Set standard door coordinates. 
UINT dstY = 52; 


UINT dibY 
UINT dibH 


193; 
135; 


// Set special door coordinates for floor 1. 
if (pDoc->m_floorNum == 1) 


} 


dstY = 99; 
dibY = 239; 
dibH = 89; 


// Perform four frames of animation. 
for (int i=@; i<4; ++i) 


{ 


// Calculate and redraw the 3-D view. 
CalcView(FALSE) ; 
DrawView(); 


// Display door parts every frame except the last. 
if (i < 3) 
{ 
// Show the left side of the opening door. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
52, dstY, m_pPartsDib, 
334+i*15, dibY, 52-i*15, dibH); 


// Show the right side of the opening door. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
134+i*15, dstY, m_pPartsDib, 
386, dibY, 52-i*15, dibH); 
} 


// Display the new 3-D scene. 
WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, @, @); 


// Play the opening-door sound effect. 
sndPlaySound("DOOR.WAV", SND SYNC ! SND_NODEFAULT) ; 


void CAztecView: :DisplayStats() 


{ 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Select a black brush. 
clientDC.SelectStock0Object (BLACK_BRUSH) ; 


// Erase the old stats. 
for (UINT i=0; i<6; ++i) 


clientDC.Rectangle(470, 159+1*20, 502, 175+i*20); 
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Listing C.6 Continued 


// Create and display the statistics text strings. 
char s[10]; 

clientDC.SetTextColor (RGB(255,0,0) ); 
clientDC.SetBkColor (RGB(0,0,Q) ); 
wsprintf(s, "%d", pDoc->m_playerLevel) ; 
clientDC.TextOut(47@, 159, s, strlen(s)); 
wsprintf(s, "%d", pDoc->m_playerExper) ; 
clientDC.TextOut(47®, 179, s, strlen(s)); 
wsprintf(s, "%d", pDoc->m_playerHP) ; 
clientDC.TextOut(470, 199, s, strlen(s)); 
wsprintf(s, "%d", pDoc->m_playerGold) ; 
clientDC.TextOut(470, 219, s, strlen(s)); 
wsprintf(s, "%d", pDoc->m_playerAttack) ; 
clientDC.TextOut(470, 239, s, strlen(s)); 
wsprintf(s, "%d", pDoc->m_playerDefense) ; 
clientDC.TextOut(47@, 259, s, strlen(s)); 


} 
void CAztecView: :UpdateExper(int exp) 
{ 
pDoc->m_playerExper += pDoc->m_floorNum * exp; 
CheckLevel() ; 
} 
void CAztecView: :CheckLevel() 
{ 
// Get the player's current experience. 
UINT experience = pDoc->m_playerExper; 
// Get the experience needed to attain the next level. 
UINT experNeeded = m_nextLevel[pDoc->m_playerLevel-1]; 
// If the player has enough experience, advance 
// him to the next level. 
if (experience >= experNeeded) 
{ 
MessageBox("Your level is increased", "Level", MB_OK) ; 
pDoc->m_playerLevel += 1; 
DisplayStats(); 
} 
} 


void CAztecView: :ShowMonster(UINT squareNum) 
{ 
// Coordinates for placing monsters in the WinG bitmap. 
int monstercoords[13][6] = 
{ 
0, ©, ©, ©, @, 0, 
0, 0, 0, 0, 0, 0, 
19, 88, 208, 360, 74, 74, 
155, 88, 208, 360, 74, 74, 
80, 88, 208, 360, 74, 74, 
0, 78, 34, 360, 70, 104, 
169, 78, ©, 360, 70, 104, 


} 
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67, 78, ©, 360, 104, 104, 
©, 52, 120, ©, 60, 180, 
179, 52, ©, ©, 60, 180, 
36, 52, ©, ©, 180, 180, 
0, ©, ©, ©, ©, 2, 

0, 0, ©, 0, ©, © 

}; 


// Get a pointer to the appropriate monster images. 
CDib* pMonsterDib = GetMonsterDib(m_objNums[squareNum] ) ; 


// Get a pointer to the monster bitmap's 

// BITMAPINFO structure. 

LPBITMAPINFO pBmInfo = 
pMonsterDib->GetDibInfoPtr() ; 


// Blit the monster image to the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
monstercoords[squareNum][®], 
monstercoords[squareNum][1], 
pMonsterDib, 
monstercoords[squareNum] [2], 
monstercoords[squareNum] [3], 
monstercoords[squareNum] [4], 
monstercoords[squareNum][5], 253); 


CDib* CAztecView: :GetMonsterDib(UINT monsterNum) 


{ 


} 


CDib* pMonsterDib; 


// Choose a monster bitmap based on 
// the monster's item number. 
switch(monsterNum) 
{ 
case @: pMonsterDib 
case 1: pMonsterDib 
case 2: pMonsterDib 


pDoc->m_pMonsterADib; break; 
pDoc->m_pMonsterBDib; break; 
pDoc ->m_pMonsterCDib; 


} 


return pMonsterDib; 


[ILILILILIL III IIIA 
PULTTTTL TALL TTA AAA AAA AAT TTT 
// END CUSTOM CODE 

FILLTTTTTT TTT T ALTA TATA AAA AAT A TTT 
FITTTTTTTT ATA T TTT TATAAAATTAAA TTT ATAA 


void CAztecView: :OnTimer(UINT nIDEvent) 


// TODO: Add your message handler code here and/or call default 
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Listing C.6 Continued 


CINILI TIELT TEATE] 
CIIILE INAIANEI TITILA 
// START CUSTOM CODE 

TITTTTTTTTTTTT TTT TTT TTT A 
[I/III TTT TTT TTT 


// Check whether the player is still alive. 
if (pDoc->m_playerHP <= Q) 


{ 
// If the player is dead, turn off the timer. 
KillTimer (1); 
// End the game. 
PlayerDead(); 
return; 
} 


// Define a static variable to hold the 
// number of the last monster image displayed. 
static UINT lastNum = 3; 


// Redraw the 3-D view in the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 


// Get a random number for the next animation frame. 
UINT rndNum; 
do 
rndNum = rand() % 4; 
while (rndNum == lastNum) ; 
lastNum = rndNum; 


// Perform the next fight action. 
DoNextMonsterFrame (rndNum) ; 


ILILILILIL 
LILIU AAAA EAA TEE 
// END CUSTOM CODE 

CIIILE EIAN A ECT ICEA 
FOSILO IILL ILTAA ARAL A 


CView: :OnTimer (nIDEvent) ; 


} 


[ILILILILIL 
FITITTTITTTT TTT TTT TTT TTT TT 
// START CUSTOM CODE 

FULTITTTTTTTT TTT TATA 
[ILILILILIL 


void CAztecView: :FightMonster() 
{ 


} 
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// Get a pointer to the appropriate 
// set of monster images. 
CDib* pMonsterDib = GetMonsterDib(m_monsterNum) ; 


// Redraw the 3-D view in the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 


// Blit the monster-hit image to the WinG bitmap. 
CopyDIBToWinGTrns ((BYTE*)m_pWinGDibBits, 

36, 52, pMonsterDib, 

©, 180, 180, 180, 253); 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Display the WinG bitmap in the window. 

SelectPalette(clientDC.m_hDC, m_hPalette, FALSE) ; 

RealizePalette(clientDC.m_hDC) ; 

WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, 0, 0); 


// Play the monster-hit sound effect. 
sndPlaySound("HIT.WAV", SND_SYNC {| SND_NODEFAULT) ; 


// Start a Windows timer to time the animation. 
SetTimer(1, 1000, 0); 


void CAztecView: :DoNextMonsterFrame(UINT num) 


{ 


// Get a pointer to the appropriate monster images. 
CDib* pMonsterDib = GetMonsterDib(m_monsterNum) ; 


if (num == 0) 
{ 
// Draw the monster-attacking image 
// on the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
360, ©, 180, 180, 253); 


// Subtract damage from the player's hit points. 
int damage = (m_monsterNum+1) * pDoc->m_floorNum - 
pDoc ->m_playerDefense; 
if (damage < ®) damage = Q; 
pDoc->m_playerHP -= damage; 
} 


else if (num == 1) 


// Draw the monster-waiting image #1 
// on the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
©, ©, 180, 180, 253); 
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Listing C.6 Continued 


else if (num == 2) 


// Draw the monster-waiting image #2 
// on the WinG bitmap. 
CopyDIBToWinGTrns((BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
180, ©, 180, 180, 253); 


else if (num == 3) 
{ 
// Draw the monster-hit image on the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
©, 180, 180, 180, 253); 


// Deduct damage from the monster's hit points. 
m_monsterHP -= 
pDoc->m_playerLevel + pDoc->m_playerAttack; 


} 


// Get a DC for the window. 
CClientDC clientDC(this) ; 


// Display the completed animation frame. 

SelectPalette(clientDC.m_hDC, m_hPalette, FALSE); 

RealizePalette(clientDC.m_hDC) ; 

WinGBitBlt(clientDC.m_hDC, 51, 51, 240, 240, 
m_hWinGDC, ©, Q); 


// Play the appropriate sound effect. 
switch (num) 
{ 
case 0: 
sndPlaySound("WOUND.WAV", 
SND_SYNC ; SND_NODEFAULT) ; 
break; 


case 3: 
sndPlaySound("HIT.WAV", 
SND_SYNC ; SND_NODEFAULT) ; 
break; 


} 


// Show the player's statistics. 
DisplayStats(); 


// If the monster is out of hit 

// points he's dead (hurray!). 

if (m_monsterHP <= @) 
KillMonster (&clientDC) ; 
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void CAztecView: :KillMonster(CClientDC* pClientDC) 


} 


// Get a pointer to the appropriate monster images. 
CDib* pMonsterDib = GetMonsterDib(m_monsterNum) ; 


// Start loop for a four-frame animation. 
for (UINT i=0; i<4; ++i) 


{ 
// Redraw the 3-D scene in the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 
// If it's not the last frame... 
if (i < 3) 
// Blit the next monster animation 
// frame to the WinG bitmap. 
CopyDIBToWinGTrns( (BYTE*)m_pWinGDibBits, 
36, 52, pMonsterDib, 
i*180, 180, 180, 180, 253); 
// Display the next animation frame in the window. 
WinGBitBlt(pClientDC->m_hDC, 51, 51, 240, 240, 
m_hWinGDC, ©, @); 
// Play the dissolving-creature sound effect. 
af Gi. <3) 
sndPlaySound("DISSOLVE.WAV", SND_SYNC ; SND_NODEFAULT) ; 
} 
// Turn off the timer and reset the fighting flag. 
KillTimer(1); 


m_fighting = FALSE; 


// Give the player experience points. 
pDoc->m_playerExper += 
(m_monsterNum + 1 + pDoc->m_floorNum) * 3; 


// Display the player's new statistics and check 
// whether the player has earned the next level. 
DisplayStats(); 

CheckLevel() ; 


// If the player has defeated the boss monster, 

// move the player to the next floor. 

if ((pDoc->m_playerX == 29) && (pDoc->m_playerY == 1)) 
StartNextFloor(); 


void CAztecView: :StartNextFloor() 


// Tell the player he's completed the floor. 
MessageBox( "You finished the floor.", 
"Level", MB_OK); 
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Listing C.6 Continued 


// Tell the document to load bitmaps 

// for the next floor. If pDoc->StartNextFloor() 
// returns TRUE, there are no other bitmaps and 
// the game is over. 

m_gameOver = pDoc->StartNextFloor() ; 


// If the game isn't over, set up the next floor. 

if (!m_gameOver) 

{ 
// Delete the old WinG DC, bitmap, and identity palette. 
DeleteWinGStuf f (); 


// Create the new WinG DC, 
// bitmap, and identity palette. 
SetUpWinGStuf f () ; 


// Initialize variables. 
InitNewGame() ; 


// Get a pointer to the "Parts A" bitmap. 
m_pPartsDib = pDoc->m_pPartsADib; 


// Redraw the 3-D view in the WinG bitmap. 
CalcView(FALSE) ; 
DrawView() ; 


// Force the window to display the new screen. 
Invalidate (FALSE) ; 
} 
else 
// If there's no other floor, the player has won. 
PlayerWins() ; 
} 


void CAztecView: :HandlePotions() 
{ 
// Ask whether the player wants to use an elixir. 
UINT result = MessageBox("Do you want to use Elixir?", 
"Elixir", MB_ICONQUESTION {| MB_YESNO); 


// If the player answers Yes... 
if (result == IDYES) 
{ 
// Take away one elixir and 
// add to the player's hit points. 
pDoc->m_potionCount -= 1; 
pDoc->m_playerHP += 
pDoc ->m_potionValues[pDoc->m_potionCount] ; 
if (pDoc->m_playerHP > 100) 
pDoc ->m_playerHP = 100; 


// Update the statistics and elixirs on the display. 
DisplayStats(); 
DisplayPotions(); 


} 
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void CAztecView: :PlayerDead() 


{ 


} 


// Set game-over flag. 
m_gameOver = TRUE; 


// Blit the player-dead image to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
©, ©, pDoc->m_pSundryDib, 400, 0, 240, 240); 


// Force the window to repaint itself. 
Invalidate (FALSE); 


// Display the player's final score. 
ShowScore(); 


void CAztecView: :PlayerWins() 


{ 


} 


// Set the game-over flag. 
m_gameOver = TRUE; 


// Blit the player-wins image to the WinG bitmap. 
CopyDIBToWinG( (BYTE*)m_pWinGDibBits, 
©, ©, pDoc->m_pSundryDib, 400, 240, 240, 240); 


// For the window to repaint. 
Invalidate(FALSE) ; 


// Display the player's final score. 
ShowScore(); 


void CAztecView: :ShowScore() 


{ 


} 


// Calculate the player's score. 
UINT score = (pDoc->m_playerLevel * 1000) + 
pDoc->m_playerExper + pDoc->m_playerGold; 


// Build the score display string. 
char s[25]; 
wsprintf(s, "Your Score: %d", score); 


// Show the score display string. 
MessageBox(s, "Score", MB_OK); 


TULTTTTTTTTTTT TTT TTT TTT TTT 
TULTTTTTTTTTTT TTT ATT TTT ATTA 
// END CUSTOM CODE 

FITTTTTTTTTTT TTT TTT TATA 
FIALS 
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Porting betwee 
Visual C++ 2.0 

Visual C++ 1.5x 


All the programs in this book were developed with Visual C++ 2.0, which 
runs only under Windows NT or Windows 95 and creates 32-bit applications. 
If you’re using Visual C++ 1.5x under Windows 3.1x, you can still create the 
applications presented in this book. However, you must change the source 
code to run under a 16-bit environment. In addition, Visual C++ 1.5x’s 
Visual Workbench does some things slightly different from Visual C++ 2.0. 
In the sections that follow, you'll get tips on building programs with 

Visual C++ 1.5x. 


Dealing with Pointers 


Because a 32-bit application runs in a flat (unsegmented) memory space, 
there’s no need to use the far or huge keywords when declaring pointers. 
However, 16-bit applications don’t enjoy this luxury. If you use the wrong 
types of pointers, you will be unable to address memory properly. For ex- 
ample, if you don’t declare a pointer to a bitmap’s image as huge, you may 
find that when you increment the pointer, it wraps around to an offset of O 
before you reach the end of the bitmap. 
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Although there’s no room here for a complete discussion of pointer types, 
you should be able to find such a discussion in any complete C++ book. You 
should know, however, that you only need to worry about data types and 
functions that you add to the program generated by Visual C++’s AppWizard. 
That is, all data and functions generated by Visual C++ already define point- 
ers and return values appropriate to the selected memory model. 


As an example of changing the listings for use with Visual C++ 1.5, I’ve cre- 

ated a 16-bit version of the CDib class. The new class is shown in listings D.1 

and D.2. You can also find the listings on this book’s CD-ROM, in the 16BIT 
directory. 


Listing D.t CDIB.H—The Header File for the 16-Bit CDib Class 


FIEFIA LLIA ACISINI ENEIT AAT TATA TATA TA TL 
// CDIB.H: Header file for the DIB class. 


TILTTTTTTAT LTT ATTA TTT AAA AAA TATA AA AA AT 


#ifndef _ _CDIB_H 
#define _ _CDIB_H 


class CDib : public CObject 

{ 

protected: 
LPBITMAPFILEHEADER m_pBmFileHeader ; 
LPBITMAPINFO m_pBmInfo; 
LPBITMAPINFOHEADER m_pBmInfoHeader ; 
RGBQUAD far* m_pRGBTable; 
BYTE huge* m_pDibBits; 
UINT m_numColors; 


public: 
CDib(const char far* fileName) ; 
~CDib(); 


DWORD GetDibSizeImage() ; 

UINT GetDibWidth() ; 

UINT GetDibHeight () ; 

UINT GetDibNumColors() ; 
LPBITMAPINFOHEADER GetDibInfoHeaderPtr () ; 
LPBITMAPINFO GetDibInfoPtr() ; 

LPRGBQUAD GetDibRGBTablePtr() ; 

BYTE huge* GetDibBitsPtr(); 


protected: 
void LoadBitmapFile(const char far* fileName) ; 


#endif 
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Listing D.2 CDIB.CPP—The Implementation File for the 16-Bit CDib 


Class 


TILTTTTTTTTT TTT TTT ATT ATTA ATTA ATT ATT TTT TTT 
// CDIB.C: Implementation file for the DIB class. 
FILTTITTTTT TTT TATA TTT TTT TTT TTT TATA 


#include "stdafx.h" 
#include "cdib.h" 
#include "windowsx.h" 


TITTTTTTITIT INIAN LATERE IA TILLAT EE AAT ECTE 
// CDib::CDib() 

VIININ TTT TTT ALETAN A LIAA 
CDib::CDib(const char far* fileName) 


{ 
// Load the bitmap and initialize 
// the class's data members. 
LoadBitmapFile(fileName) ; 

} 


PULTITTTTTTT TATA ATT TTT AAA 
// CDib::~CDib() 
SIANAIL TTT TAT ATTA TTT TTT TL 
CDib: :~CDib() 
{ 
// Free the memory assigned to the bitmap. 
GlobalFreePtr (m_pBmInfo) ; 


} 


FILTTTTTTIT TTT TTT TTA TTT TATA ATTA TAT TTL 
// CDib: :LoadBitmapFile() 
// 
// This function loads a DIB from disk into memory. It 
// also initializes the various class data members. 
eee eee 
void CDib::LoadBitmapFile 

(const char far* fileName) 
{ 

// Construct and open a file object. 

CFile file(fileName, CFile::modeRead) ; 


// Read the bitmap's file header into memory. 
BITMAPFILEHEADER bmFileHeader; 
file.Read((void far*)&bmFileHeader, sizeof (bmFileHeader) ) ; 


// Check whether the file is really a bitmap. 
if (bmFileHeader.bfType != 0x4d42) 
{ 
AfxMessageBox("Not a bitmap file"); 
m_pBmFileHeader = Q; 
m_pBmInfo = 0; 
m_pBmInfoHeader = 0; 
m_pRGBTable = 0; 


(continues) 
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Listing D.2 Continued 


m_pDibBits = 0; 
m_numColors = 0; 


// If the file checks out okay, continue loading. 


else 


{ 


} 


// Calculate the size of the DIB, which is the 

// file size minus the size of the file header. 
DWORD fileLength = file.GetLength() ; 

DWORD dibSize = fileLength - sizeof (bmFileHeader) ; 


// Allocate enough memory to fit the bitmap. 
BYTE huge* pDib = 
(BYTE huge*)GlobalAllocPtr(GMEM_MOVEABLE, dibSize) ; 


// Read the bitmap into memory and close the file. 
file.ReadHuge((void far*)pDib, dibSize) ; 
file.Close(); 


// Initialize pointers to the bitmap's BITMAPINFO 
// and BITMAPINFOHEADER structures. 

m_pBmInfo = (LPBITMAPINFO) pDib; 

m_pBmInfoHeader = (LPBITMAPINFOHEADER) pDib; 


// Calculate a pointer to the bitmap's color table. 
m_pRGBTable = 
(RGBQUAD far*)(pDib + m_pBmInfoHeader ->biSize) ; 


// Get the number of colors in the bitmap. 
int m_numColors = GetDibNumColors() ; 


// Calculate the bitmap image's size. 
m_pBmInfoHeader ->biSizeImage = 
GetDibSizeImage() ; 


// Make sure the biClrUsed field 

// is initialized properly. 

if (m_pBmInfoHeader ->biClrUsed == 0) 
m_pBmInfoHeader ->biClrUsed = m_numColors; 


// Calculate a pointer to the bitmap's actual data. 
DWORD clrTableSize = m_numColors * sizeof (RGBQUAD) ; 
m_pDibBits = 

pDib + m_pBmInfoHeader->biSize + clrTableSize; 


IAALVIIA AAVA INA LANEAN EIA LAA TAFITI EEEN 
// CDib::GetDibSizeImage() 


// 


// This function calculates and returns the size of the 
// bitmap's image in bytes. 
TLILITTTT ATTA ATTA TTT TATA ATT 
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DWORD CDib: :GetDibSizeImage() 


{ 


} 


// If the bitmap's biSizeImage field contains 
// invalid information, calculate the correct size. 
if (m_pBmInfoHeader ->biSizeImage == 0) 


{ 


} 


// Get the width in bytes of a single row. 
DWORD byteWidth = (DWORD) GetDibWidth() ; 


// Get the height of the bitmap. 
DWORD height = (DWORD) GetDibHeight() ; 


// Multiply the byte width by the number of rows. 
DWORD imageSize = byteWidth * height; 


return imageSize; 


// Otherwise, just return the size stored in 
// the BITMAPINFOHEADER structure. 


else 


return m_pBmInfoHeader ->biSizeImage; 


TULLANAN ALIA TTT TT ATTA AA AATETTA I 
// CDib::GetDibWidth() 


l1 


// This function returns the width in bytes of a single 

// row in the bitmap. 

ILILILILIL AAAA TAAA 
UINT CDib::GetDibWidth() 


{ 
} 


return (UINT) m_pBmInfoHeader ->biWidth; 


FIILIS TANINI EANA TTT TTA ATTA TA TATA TL 
// CDib: :GetDibHeight () 


// 


// This function returns the bitmap's height in pixels. 
TITTLTTTTT TATA TATA TAT TTT TAA TTT ATT 
UINT CDib: :GetDibHeight () 


{ 
} 


return (UINT) m_pBmInfoHeader ->biHeight; 


TLTLTLTTTTTT TTT TATA TAAL AAT TATA TATA TAT A TTT 
// CDib::GetDibNumColors() 


// 


// This function returns the number of colors in the 

// bitmap. 

TLTTTTTTTTT TTT TTA AAT ATTA ATTA TTA TAT AT 
UINT CDib::GetDibNumColors() 


{ 


if ((m_pBmInfoHeader->biClrUsed == @) && 


(m_pBmInfoHeader ->biBitCount < 9)) 
return (1 << m_pBmInfoHeader->biBitCount) ; 
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Listing D.2 Continued 


else 
return (int) m_pBmInfoHeader ->biClrUsed; 
} 


FLLLTTTTTTTT TEACA TTT TATA TTT ATALII TATA ATT 
// CDib::GetDibInfoHeaderPtr () 

// 

// This function returns a pointer to the bitmap's 

// BITMAPINFOHEADER structure. 

VOULIO ATALETAN TTT TTT TATA TATA TT ATT TATA TTL 
LPBITMAPINFOHEADER CDib: :GetDibInfoHeaderPtr () 

{ 


} 


VIININ ANIA TATANAN LINAN IAAI ATTA TTT TTT TATA TT TTL 
// CDib::GetDibInfoPtr() 

// 

// This function returns a pointer to the bitmap's 

// BITMAPINFO structure. 

FITTLTTTTTT TTT TTT CITITAN ELALI TTT TTA TTA TATA TL 
LPBITMAPINFO CDib: :GetDibInfoPtr () 

{ 


} 


FILTITTTTTT TTT TTT NANIA CAAA ATT TTT TTT TTT TTT TL 
// CDib::GetDibRGBTablePtr() 

// 

// This function returns a pointer to the bitmap's 

// color table. 
eee 
LPRGBQUAD CDib::GetDibRGBTablePtr () 

{ 


} 


TILTTTTTTIT IANA TTT TTT TT ATTA TATA TTT TATA TTT H 
// CDib::GetDibBitsPtr() 

// 

// This function returns a pointer to the bitmap's 

// actual image data. 

FILTTITTTTT TTT TTT TTT TTT TTT TTT TATA TT ATTA TTT TTL 
BYTE huge* CDib::GetDibBitsPtr () 

{ 


return m_pBmInfoHeader; 


return m_pBmInfo; 


return m_pRGBTable; 


return m_pDibBits; 


} 
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Using Visual C++ 1.5 


When creating this book’s applications with Visual C++ 1.5x, you can gener- 
ally follow the step-by-step instructions given in each chapter. However, you 
will discover that Visual C++ 1.5x often works differently than Visual C++ 
2.0. The most important differences are the following: 


E AppWizard. Although Visual C++ 1.5x’s AppWizard creates the same 
type of applications that Visual C++ 2.0 does, it looks and operates 
differently. If you need instruction on using AppWizard, please consult 
your Visual C++ documentation. 


E AppStudio. AppStudio, too, works differently in Visual C++ 1.5x. More- 
over, it is not as tightly incorporated into the Visual C++ development 
environment. If you need instruction on using AppStudio, please con- 
sult your Visual C++ documentation. 


E ClassWizard. In Visual C++, ClassWizard cannot add overloaded func- 
tions such as PreCreateWindow() and DeleteContents(). You must add 
these functions “by hand” to your code. This means placing function 
declarations in the appropriate header file and the function definitions 
in the matching implementation file. 


E Projects. In Visual C++ 1.5x, you add files to projects using the Project 
menu’s Edit command. In addition, you load project files using the 
Project menu’s Open command. You will probably stumble upon 
other differences between the way Visual C++ 1.5x and Visual C++ 2.0 
handle projects. Consult your Visual C++ documentation for more 
information. 


Library Files. When adding libraries to a Visual C++ 1.5x project, you 
must be sure to select the 16-bit version of the library. Specifically, use 
WING.LIB instead of WING32.LIB. 


To give you a head start, I created a 16-bit version of the WINGEX sample 
program from Chapter 4. That program is shown in listings D.3 through D.6. 
In these listings, code that you must add manually is shown between double 
lines of slash characters. Code that you add using ClassWizard is listed nor- 
mally—that is, it is not shown between double lines of slash characters. Files 
that were created by AppWizard, but which you need not modify, are not 
shown here. If you’d like to know what the unlisted files contain, load them 
from disk using Visual C++ or some other text editor. The full program can be 
found on this book’s CD-ROM in the 16BIT\WINGEX 16 directory. 
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Listing D.3 MAINFRM.H—The Header File for the 16-Bit 


CMainFrame Class 


// mainfrm.h : interface of the CMainFrame class 
// 
LILTLTTTTTTTTT TTT TTT TTT TTT EAA TTI 


class CMainFrame : public CFrameWnd 


protected: // create from serialization only 
CMainFrame(); 
DECLARE_DYNCREATE (CMainFrame ) 


[ILILILILIL 
LIIIN LIAA AA A EAA AEEA AT 
// START CUSTOM CODE 

TITTITITTTTTT EA TIANI TAT TTT TTL 
FITTLTITTTTTTTTT TTT TATA TATA 


BOOL CMainFrame: :PreCreateWindow(CREATESTRUCT& cs); 


TILLITI AAA EI AEA TTL 
IDILI TIALLE ELA AA NAT A ECA E 
// END CUSTOM CODE 

CLIII VLA AAAA AALIS IATA ATIT 
ILILILILIL ECA ALELLA 


// Attributes 
public: 


// Operations 
public: 


// Implementation 
public: 
virtual ~CMainFrame(); 
#ifdef _DEBUG 
virtual void AssertValid() const; 
virtual void Dump(CDumpContext& dc) const; 
#endif 


// Generated message map functions 
protected: 
//{{AFX_MSG(CMainFrame) 
// NOTE - the ClassWizard will add and remove member functions 


// here. 
// DO NOT EDIT what you see in these blocks of generated 
// code! 


//}}AFX_MSG 
DECLARE_MESSAGE_MAP( ) 


}; 
PETITIA TAITAI TINISI LTLID AAA AAA AAA AA TA AAA AAT AAA TAA AAA TAAL 
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Listing D.4 MAINFRM.CPP—The Implementation File for the 16-Bit 


CMainFrame Class 


// mainfrm.cpp : implementation of the CMainFrame class 
// 


#include "stdafx.h" 
#include "wingex.h" 


#include "mainfrm.h" 


#ifdef DEBUG 

#undef THIS FILE 

static char BASED_CODE THIS _FILE[] = _ _FILE__; 
#endif 


TINITIIS ITIITI TTT AAA AAA AT TATA TTT 
// CMainFrame 


IMPLEMENT_DYNCREATE(CMainFrame, CFrameWnd) 
BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) 


//{{AFX_MSG_MAP (CMainFrame) 
// NOTE - the ClassWizard will add and remove mapping macros 


// here. 
// DO NOT EDIT what you see in these blocks of generated 
// code! 


/ /}}AFX_MSG_MAP 
END_MESSAGE_MAP() 


TIIIIIAITI TTT AAA ATT ATTA ATTA TT 
// CMainFrame construction/destruction 


CMainFrame: :CMainFrame() 


{ 
// TODO: add member initialization code here 
} 
CMainFrame: :~CMainFrame() 
{ 
} 


FIIIT EATAA IAAT IIIA AIAI ILAT TTT TTT 
// CMainFrame diagnostics 


#ifdef _DEBUG 
void CMainFrame::AssertValid() const 


{ 
CFrameWnd: :AssertValid(); 


} 


void CMainFrame: :Dump(CDumpContext& dc) const 


{ 


(continues) 
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Listing D.4 Continued 


CFrameWnd: :Dump(dc) ; 
} 


#endif //_DEBUG 


FELTITTTTTTIT TITTLE T A TTT ATTA ATII PAIA 
// CMainFrame message handlers 


LELLE ALLTA TTT TTT TTT TATA TTT 
CALIL LIAA IANA TTT TAT TTT 
// START CUSTOM CODE 

TUSATA CEATA EET AAAA 
ANISA EIECINE TTT TATA TTT 


BOOL CMainFrame: :PreCreateWindow(CREATESTRUCT& cs) 
{ 

// Call base class's version. 

CFrameWnd: :PreCreateWindow(cs) ; 


// Set the main window's width and height. 
cS .Ccx 350; 
cs.cy 385; 


return TRUE; 
} 


TITITITTTTTTTT TTT LILIANA TACY 
FIL TANF LAITIITI ATTA TTT ATT 
// END CUSTOM CODE 

TITITITITTTT TTT TTT IAN AAI AATE lT 
TITITITTTTTTTT TATA IALTA ATAA 


Listing D.5 WINGEVW.H—The Header File for the 16-Bit 
CWingexView Class 


// wingevw.h : interface of the CWingexView class 
// 
PANAL EENAA IASA TTT ATTA 


ILTAISIN AAAA TISERE I 
LALALA TAI TAL A AETAT NELLI 
// START CUSTOM CODE 

KASAENAN TTT TTT TAT 
COILLA TATA AAT AAEE TTT TTT 


#include "c:\wing\include\wing.h" 
#include "cdib.h" 


typedef struct BmInfo 


{ 
BITMAPINFOHEADER Header; 
RGBQUAD aColors[ 256]; 

} BmInfo; 


const WINGDIBWIDTH = 300; 
const WINGDIBHEIGHT = 300; 


[IIIT TTT TTT TAT TTT 
[I/III III IIIN 
// END CUSTOM CODE 

HEILE I AAAA EAEE AT ELELE 
TALLINNAL AAA AAAA TAITEET 


class CWingexView : public CView 

{ 

protected: // create from serialization only 
CWingexView(); 
DECLARE_DYNCREATE (CWingexView) 


// Attributes 
public: 
CWingexDoc* GetDocument(); 


TITTTTTTTTT TTT TTT TAT TAAL 
FITTTTTTTTT TTT ATTA TATA TAT ATT TTT 
// START CUSTOM CODE 

FTTTTTTTTTTT ATTA TTT ATTA TAT 
TIILIEN FIAI LIIVI TATA TTT TT 


protected: 
HBITMAP m_hOldBitmap; 
HDC m_hWinGDC; 
BmInfo m_WinGBmInfo; 
void huge* m_pWinGDibBits; 
LONG m_orientation; 
HPALETTE m_hPalette; 
CDib* m_pSceneDib; 
CDib* m_pPropDib; 
UINT m_frameNum; 


TIITTTTTTITTTT TTT TTT TATA TTT TAT 
TILTTTTTTTTTTTT TTT ATT ATTA TATA TTT 
// END CUSTOM CODE 

INIIAI TAAA TATA TTA 
FITTTTTTTTT ATT T TTT TAAL 


// Operations 
public: 


// Implementation 
public: 
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Listing D.5 Continued 


virtual ~CWingexView() ; 

virtual void OnDraw(CDC* pDC); // overridden to draw this view 
#ifdef _DEBUG 

virtual void AssertValid() const; 

virtual void Dump(CDumpContext& dc) const; 
#endif 


protected: 


PETLTTTTTTTT TTT TTT TATA AAT AA TT 
LIILIA ETA HA 
// START CUSTOM CODE 

VEALIA ALLIANS ITAIT EE AAN AI d, 
LICIS CUIA LEELA ATTA ATA ATA 


void CreateWinGDibPalette(); 
//void CopyDIBToWinG(BYTE huge* m_pWinGBmBits, CDib* pDib); 
void CreateIdentityPalette(BmInfo* winGBmInfo, 
CDib* pDib) ; 
void CopyDIBToWinG(BYTE huge* m_pWinGBmBits, 
UINT dstX, UINT dstY, CDib* pDib, 
UINT frmX, UINT frmY, UINT frmW, UINT frm) ; 
void CopyDIBToWinGTrns (BYTE huge* m_pWinGBmBits, 
UINT dstX, UINT dstY, CDib* pDib, 
UINT frmX, UINT frmY, UINT frmW, UINT frmH, 
UINT trnsColor) ; 


FILII ITA IAAL ATT TTT TAA ATA TTT 
ITALIANI IAIA TATA TATA ATTA TTT 
// END CUSTOM CODE 

[1111111111111 IIIT 
CIVITANAN TATEA EAI MATALAA A 


// Generated message map functions 
protected: 
//{{AFX_MSG (CWingexView) 
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct) ; 
afx_msg void OnDestroy(); 
afx_msg void OnTimer(UINT nIDEvent) ; 
/ /}}AFX_MSG 
DECLARE_MESSAGE_MAP() 


}; 


#ifndef _DEBUG // debug version in wingevw.cpp 
inline CWingexDoc* CWingexView: :GetDocument () 

{ return (CWingexDoc*)m_pDocument; } 
#endif 


TITTLTTLT TAT TATA AT TATA TATA ATTA AAA AAT AAA AAAA TT AT TTT 
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Listing D.6 WINGEVW.CPP—The Implementation File for the 16-Bit 


CWingexView Class 


// wingevw.cpp : implementation of the CWingexView class 
// 


#include "stdafx.h" 
#include "“wingex.h" 


#include "wingedoc.h" 
#include "wingevw.h" 


#ifdef _DEBUG 

#undef THIS FILE 

static char BASED CODE THIS FILE[] = _ _FILE__; 
#endif 


IIIN ETA AAA LEILAN TTT TTT TTT TTT ATA TAA TAAL 
// CWingexView 


IMPLEMENT_DYNCREATE (CWingexView, CView) 


BEGIN MESSAGE _MAP(CWingexView, CView) 

//{{AFX_MSG_MAP (CWingexView) 
ON_WM_CREATE() 
ON_WM_DESTROY ( ) 
ON_WM_TIMER() 
//}}AFX_MSG_MAP 

END_MESSAGE_MAP() 


TTTTITTITTTTT TTT TTT TTT ATTA AA AAA AA 
// CWingexView construction/destruction 


CWingexView: :CWingexView( ) 


{ 
// TODO: add construction code here 


[I/III ITIITI 
TALALTAL IAAL A TTT TATA TTT TTA EEA 
// START CUSTOM CODE 

CUIL IAA ETA TANITTI AAAA 
FITTTTTTTTTT TTT TALAIA AI AFEA TITIA 


// Load the SCENE.BMP file. 
m_pSceneDib = new CDib("scene.bmp") ; 


// Load the bitmap containing the animation frames. 
m_pPropDib = new CDib("prop.bmp") ; 


// Check what type of DIB we should use. 
WinGRecommendDIBFormat ( (BITMAPINFO*)&m_WinGBmInfo) ; 


// Save the recommended orientation. 
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Listing D.6 Continued 


m_orientation = m_WinGBmInfo.Header.biHeight ; 


// Fill in the BITMAPINFO structure with values 
// to create a 256-color 300x300 WinG bitmap. 
m_WinGBmInfo.Header.biBitCount = 8; 
m_WinGBmInfo.Header.biCompression = BI_RGB; 
//m_WinGBmInfo.Header.biWidth = 300; 
//m_WinGBmInfo.Header.biHeight = 300 * m_orientation; 
m_WinGBmInfo.Header.biWidth = WINGDIBWIDTH; 
m_WinGBmInfo.Header.biHeight = 

WINGDIBHEIGHT * m_orientation; 


// Copy the screen colors into the WinG bitmap 
// and create a logical palette. 
//CreateWinGDibPalette(); 


// Create an identity palette based on the 
// CDib object's 256-color palette. 
CreateIdentityPalette(&m_WinGBmInfo, m_pSceneDib) ; 


// Create a WinG device context. 
m_hWinGDC = WinGCreateDC() ; 


// Create a WinG bitmap compatible with the WinG DC. 
HBITMAP hBitmap = WinGCreateBitmap(m_hWinGDC, 
(LPBITMAPINFO) &m_WinGBmInfo, 
(void far* far*)&m_pWinGDibBits) ; 


// Select the WinG bitmap into the WinG DC. 
m_hOldBitmap = 
(HBITMAP)SelectObject(m_hWinGDC, hBitmap) ; 


// Clear the garbage from the WinG bitmap. 
PatBlt(m_hWinGDC, 0, @, 300, 300, BLACKNESS) ; 


// Copy the scene to the WinG bitmap. 

//CopyDIBToWinG( (BYTE huge*)m_pWinGDibBits, m_pSceneDib) ; 

CopyDIBToWinG( (BYTE huge*)m_pWinGDibBits, 0, 0, 
m_pSceneDib, 0, ©, 300, 300); 


// Initialize the frame counter. 
m_frameNum = Q; 


[IIIIIIIIIII TTT TTT TATA TATA TATA TAT 

TTLTTLTTTTTT TTT TTT TATA TATA ATA TTA TTT 

// END CUSTOM CODE 

FTLTTTTTTTTTTT TTT TATA ATTA ATTA TTL 

TTITTTTTTTTT TTT TT ATTA TTA ATA ATA 
} 


CWingexView: :~CWingexView( ) 


IAIA TIINA TTT TTT ATTA TAA ATT AAT ATT 
FELTTTTTTTTT TTT TTT TTT AAT ATTA TAT 


} 
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// START CUSTOM CODE 
[IIIIIIIIII I IITIN 
TRII IANLTIII IAA AAA NILATI A ITATTA 


// Select the old bitmap back into the WinG DC. 
HBITMAP hBitmap = 
(HBITMAP)SelectObject(m_hWinGDC, m_hOldBitmap) ; 


// Delete the WinG bitmap that the program created. 
DeleteObject(hBitmap) ; 


// Delete the WinG DC. 
DeleteDC(m_hWinGDC) ; 


// Delete the logical palette. 
DeleteObject(m_hPalette) ; 


// Delete the CDib object holding SCENE.BMP. 
delete m_pSceneDib; 


// Delete the CDib object holding PROP.BMP. 
delete m_pPropDib; 


/[/IIIIIII III IINIT 
[IIIIIIIII ITIITI 
// END CUSTOM CODE 

LIIATI TIAI IIA AAIE ITISA 
TITTTTTTTTT TT AT TTT TTT TTT 


FULTTTTTTTTT TTT TTT TTT TTT ATTA ATA AAA AAA TAT 
// CWingexView drawing 


void CWingexView: :OnDraw(CDC* pDC) 


if 


CWingexDoc* pDoc = GetDocument(); 
ASSERT_VALID(pDoc) ; 


// TODO: add draw code for native data here 


LILAS TTT TATA TTT TTT AATA 
TILTTTTTTTTTTT TTT TT TTT TTT 
// START CUSTOM CODE 

[III II TTT TATA TATA ATA 
CALIA TITALIIS TAN TTT ATTA TT 


// Select the logical palette into the window's DC. 
SelectPalette(pDC->m_hDC, m_hPalette, FALSE); 


// Tell Windows to remap the system palette with 
// the program's logical palette. 
RealizePalette(pDC->m_hDC) ; 


// Draw a rectangle on the WinG bitmap. 
//Rectangle(m_hWinGDC, 20, 20, 100, 100); 


(continues) 


529 


530 Appendix D—Porting between Visual C++ 2.0 and Visual C++ 1.5x 


Listing D.6 Continued 


// Transfer the WinG bitmap to the window's display. 
WinGBitBlt(pDC->m_hDC, 20, 20, 300, 300, m_hWinGDC, 0, 0); 


[I/III TTT ATA TAT TL 
[ILILILILIL T ATTA TT ATA TAT 
// END CUSTOM CODE 

[ILILILILIL IILI 
[IIIIIIIIII ILILILILIL 


} 


JIIIIISITCILAI LLIAIN IANA AACA ATTA TTT ATTA TAT 
// CWingexView diagnostics 


#ifdef _DEBUG 
void CWingexView: :AssertValid() const 


{ 
CView: :AssertValid() ; 
} 
void CWingexView: :Dump(CDumpContext& dc) const 
{ 
CView: :Dump(dc) ; 
} 


CWingexDoc* CWingexView::GetDocument() // non-debug version is inline 
{ 

ASSERT (m_pDocument ->IsKindOf (RUNTIME_CLASS(CWingexDoc))); 

return (CWingexDoc*)m_pDocument; 


} 
#endif //_DEBUG 


FIVLEAIJAIAILFTITA ALIIA ATANAN ELAS TTA TT 
// CWingexView message handlers 


TIILINEN LILITILE TETEA 
LIILIA AAAA AAL A 
// START CUSTOM CODE 

JACLIN ILENI AIAI AAA ATA ATT 
PITIAS EIA ACELA TAA 


void CWingexView: :CreateWinGDibPalette() 

{ 
// Define a structure for the logical palette. 
struct 


{ 
WORD Version; 


} 


/* 
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WORD NumberOfEntries; 
PALETTEENTRY aEntries[256] ; 
} logicalPalette = { 0x300, 256 }; 


// Get a device context for the screen. 
HDC hScreenDC = ::GetDC(Q) ; 


// Load the system palette into the 
// logical palette structure. 
GetSystemPaletteEntries 

(hScreenDC, 0, 256, logicalPalette.aEntries) ; 


// Get rid of the screen DC. 
::ReleaseDC(®@, hScreenDC) ; 


// Copy the system colors into the WinG bitmap's 
// color table and set the appropriate flags. 
for(int i = @;i < 256;i++) 
{ 
m_WinGBmInfo.aColors[i].rgbRed = 
logicalPalette.aEntries[i] .peRed; 
m_WinGBmInfo.aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen; 
m_WinGBmInfo.aColors[i].rgbBlue = 
logicalPalette.aEntries[i] .peBlue; 
m_WinGBmInfo.aColors[i].rgbReserved = Q; 


logicalPalette.aEntries[i].peFlags = Q; 
} 


// Create the program's logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*)&logicalPalette) ; 


void CWingexView: :CopyDIBToWinG 


{ 


(BYTE huge* m_pWinGDibBits, CDib* pDib) 


// Get the bitmap's width and height. 
UINT srcWidth = pDib->GetDibWidth() ; 
UINT srcHeight = pDib->GetDibHeight(); 


// Get a pointer to the image's data. 
BYTE huge* pDibBits = pDib->GetDibBitsPtr() ; 


// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<srcHeight; ++row) 
for (UINT col=0; col<srcWidth; ++col) 
{ 
LONG index = (LONG)row * (LONG)srcWidth + col; 
m_pWinGDibBits[index] = pDibBits[index]; 
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Listing D.6 Continued 


void CWingexView: :CopyDIBToWinG 
(BYTE huge* m_pWinGDibBits, UINT dstX, UINT dstY, 
CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frmH) 


{ 
// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight() ; 
// Get a pointer to the image's data. 
BYTE huge* pDibBits = pDib->GetDibBitsPtr() ; 
// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=@; col<frmW; ++col) 
{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmX; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstX; 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 
} 
} 


void CWingexView: :CreateIdentityPalette 
(BmInfo* winGBmInfo, CDib* pDib) 
{ 
struct 
{ 
WORD Version; 
WORD NumberOfEntries; 
PALETTEENTRY aEntries[256]; 
} logicalPalette = {0x300, 256}; 


// Get the screen DC. 
HDC Screen = ::GetDC(Q) ; 


// Copy Windows' 20 standard system colors 
// into the new logical palette. 
GetSystemPaletteEntries 
(Screen, ©, 10, logicalPalette.aEntries) ; 
GetSystemPaletteEntries 
(Screen, 246, 10, logicalPalette.aEntries + 246); 


// Get rid of the screen DC. 
::ReleaseDC(Q@,Screen) ; 
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// Copy the standard 20 system colors into 
// the WinG bitmap's color table. 
for(int i = 0; i < 10; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i] .peRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i] .peBlue; 
winGBmInfo->aColors[i].rgbReserved = 0; 


logicalPalette.aEntries[i].peFlags = 0; 


winGBmInfo->aColors[i + 246].rgbRed = 
logicalPalette.aEntries[i + 246].peRed; 
winGBmInfo->aColors[i + 246].rgbGreen = 
logicalPalette.aEntries[i + 246].peGreen; 
winGBmInfo->aColors[i + 246].rgbBlue = 
logicalPalette.aEntries[i + 246].peBlue; 
winGBmInfo->aColors[i + 246].rgbReserved = Q; 


logicalPalette.aEntries[i + 246].peFlags = 0; 
} 


// Get a pointer to the source bitmap's color table. 
LPRGBQUAD pColorTable = pDib->GetDibRGBTablePtr() ; 


// Copy the source bitmap's color table into both 
// the WinG bitmap color table and 
// into the new logical palette. 
for(i = 10; i < 246; i++) 
{ 
winGBmInfo->aColors[i].rgbRed = 
logicalPalette.aEntries[i].peRed = 
pColorTable[i].rgbRed; 
winGBmInfo->aColors[i].rgbGreen = 
logicalPalette.aEntries[i].peGreen = 
pColorTable[i].rgbGreen; 
winGBmInfo->aColors[i].rgbBlue = 
logicalPalette.aEntries[i].peBlue = 
pColorTable[i].rgbBlue; 
winGBmInfo->aColors[i].rgbReserved = 0; 
logicalPalette.aEntries[i].peFlags = 
PC_NOCOLLAPSE ; 


// Create the logical palette. 
m_hPalette = 
CreatePalette((LOGPALETTE*)&logicalPalette) ; 


} 


void CWingexView: :CopyDIBToWinGTrns 
(BYTE huge* m_pWinGDibBits, UINT dstX, UINT dstyY, 
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Listing D.6 Continued 


CDib* pDib, UINT frmX, UINT frmY, UINT frmW, UINT frmH, 
UINT trnsColor) 


// Get the bitmap's width and height. 
DWORD srcWidth = pDib->GetDibWidth() ; 
DWORD srcHeight = pDib->GetDibHeight() ; 


// Get a pointer to the image's data. 
BYTE huge* pDibBits = pDib->GetDibBitsPtr() ; 


// Copy data from the source bitmap to the WinG bitmap. 
for (UINT row=0; row<frmH; ++row) 
for (UINT col=0; col<frmW; ++col) 
{ 
DWORD newSrcY = srcHeight - frmH - frmY + row; 
if (m_orientation == -1) 
newSrcY = srcHeight - row - frmY - 1; 
DWORD srcIndex = 
newSrcY * srcWidth + col + frmx; 
DWORD newDstY = 
WINGDIBHEIGHT - frmH - dstY + row; 
if (m_orientation == -1) 
newDstY = row + dstY; 
DWORD dstIndex = 
newDstY * WINGDIBWIDTH + col + dstX; 
if (pDibBits[srcIndex] != trnsColor) 
m_pWinGDibBits[dstIndex] = pDibBits[srcIndex] ; 


} 


FUTTTTTTTTTTTTTT TTT TATA ATTA TT 
[II/III IINITAN 
// END CUSTOM CODE 

IAIL IAIN TAAA AS ULA TEIE T A 
VITITA ITET TIIT EHAA AAA 


int CWingexView: :OnCreate(LPCREATESTRUCT lpCreateStruct) 
{ 
if (CView::OnCreate(lpCreateStruct) == -1) 
return -1; 


// TODO: Add your specialized creation code here 


PANIA IATA TTT TTT TTT TATA ATA TT 
VINIA LANTA TAAA TTT TAT TTT 
// START CUSTOM CODE 

FILTTTTTTTTTTT TTT TTT TTT TT ATT TT 
FITTLTTTTTTTT TTT TTT TATA TTT TTL 


// Start a Windows timer. 
SetTimer(1, 100, 0); 


} 


VIELLE ALAL ATANI AA AAT TL 
CILLA AALL 
// END CUSTOM CODE 

FITTTTTTTTTT IIIN I IIIA 
CIIAN ATANAN TIIE CEAN 


return ð; 


void CWingexView: :OnDestroy() 


{ 


} 


CView: :OnDestroy(); 


// TODO: Add your message handler code here 


TIITLIT ALTANNA TTT ATT 
FETTTTTTTTTT TTT TTT TTT TTT 
// START CUSTOM CODE 

VISIITI TAALA AAAA AAT TIITEL. 
[ILILILILIL NIIIN 


// Destroy the Windows timer. 
KillTimer (1); 


TULLIIN ES IALINAN ANA TTT ATTA 
FITTITITTTT TTT ITT NIAI A CCEC IA 
// END CUSTOM CODE 

FITTTTTTTTTTT ATT TAT TTT TATA TA AA 
LISIINA NETANA ITAI IETA 


void CWingexView::OnTimer(UINT nIDEvent) 


{ 


Using Visual C++ 1.5 


// TODO: Add your message handler code here and/or call default 


CAAT II AAAA ATT TATA TTL 
TLTTTITTTTTTT TTT TTT TTT TATA TAT 
// START CUSTOM CODE 

LOITS TANANI ILATE AAEL 
FITTTTTTTTTT TTT TTT AATELIA TT 


// Increment the animation frame counter. 


m_frameNum += 1; 
if (m_frameNum > 7) 
m_frameNum = 0; 


UINT x, y; 


// Get the coordinates for the next frame. 


switch (m_frameNum) 


{ 
case 0: x = 1; y = 1; break; 
case 1: x = 163; y = 1; break; 
case 2: x = 325; y = 1; break; 
case 3: x = 1; y = 163; break; 


(continues) 
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Listing D.6 Continued 


case 4: x = 163; y = 163; break; 
case 5: x = 325; y = 163; break; 
case 6: x = 1; y = 325; break; 
case 7: x = 163; y = 325; 


} 


// Update the WinG bitmap by restoring the scene 

// where the last frame appeared and then 

// copying the new frame to the WinG bitmap. 

CopyDIBToWinG( (BYTE huge*)m_pWinGDibBits, 70, 70, 
m_pSceneDib, 70, 70, 230, 230); 

CopyDIBToWinGTrns( (BYTE huge*)m_pWinGDibBits, 70, 70, 
m_pPropDib, x, y, 160, 160, 255); 


// Get a device context for the window's client area. 
CDC* pClientDC = new CClientDC(this) ; 


// Select the logical palette into the window's DC. 
SelectPalette(pClientDC->m_hDC, m_hPalette, FALSE); 


// Tell Windows to remap the system palette with 
// the program's logical palette. 
RealizePalette(pClientDC ->m_hDC) ; 


// Transfer the WinG bitmap to the window's display. 
WinGBitBlt(pClientDC->m_hDC, 20, 20, WINGDIBWIDTH, 
WINGDIBHEIGHT, m_hWinGDC, @, 0); 


// Delete the window's DC. 
delete pClientDC; 


LIILIA CSALI TATA TTT TTT 
TILTIITTTTTTTT TTT TTT TTT TTT TTT ATT ATT 
// END CUSTOM CODE 

TTTLTTTTITTTT ATT TATA TTT TATA TTL 
TTTLTTLTITTT TTT TTT TTA LAL IATA TT 


CView: :OnTimer (nIDEvent) ; 


Index 


Symbols 


3-D graphics, 443-444 
offset stamping technique, 
447-448 
shading/offset stamping, 
combining, 448 
shadow technique, 445-447 
3-D RPG (role-playing 
game), 161 
3-D view (Aztec Adventure 
dungeon grids), 313-323, 
331-347, 363-367 
CalcNorthView() function, 
328-329 
CalcView() function, 
326-328 
DisplayCompass() 
function, 351 
DoForwardButton() 
function, 350-351 
DrawView() function, 
329-330 
dungeon objects, displaying, 
307-312, 353-362 
HandleForwardButton() 
function, 349 
LoadLevel() function, 
324-325 
OnLButtonDown() function, 
348-349 
OnLButtonUp() 
function, 350 
OnUpdate() function, 
325-326 
ShowMonster() function, 
401-402 
ShowScene() function, 330 
ShowTreasure() function, 
358-359 


A 


About Aztec Adventure 
command (Help menu), 288 
About dialog box, 39, 95 
About Dungeon Designer 
command (Help menu), 192 
About Showdib command 
(Help menu), 39 
About Wingex command 
(Help menu), 95 
Add Class dialog box, 222 
Add Member Function dialog 
box, 43 
Add Member Variable dialog 
box, 223 
algorithms, 12 
animation, 11-12 
antialiasing (smoothing 
graphics), 455 
AppWizard 
Aztec Adventure, 
programming, 283-288 
Dungeon Designer, 
programming, 185-192 
files (SHOWDIB), 35 
RES directory, 35 
SHOWDIB, programming, 
32-49 
WINGEX, programming, 92 
artificial intelligence, 12-13 
Audiostation program, 428 
Aztec Adventure, 161 
data/graphics files, 176-182 
doors/keys (item 
numbers), 173 
Dungeon Designer, 169-176 
programming, 185 


dungeon floors 
building, 170-171 
loading, 175-176 
printing, 174 
saving, 175-176 
switching, 168 
dungeon grids (3-D view), 
307-312 
dungeon monsters 
creating, 391 
fighting, 166 
dungeons, exploring, 
164-165 
elixir, 167 
file listings, 457-513 
item numbers/values, 
171-173 
viewing, 173-174 
keys, 166-167 
OpenDoor() function, 
378-379 
palette colors, 182 
player statistics, 381 
playing, 162-168 
sounds 
editing, 429-430 
effects, creating, 431-432 
recording, 427-429 
Version 1 
programming, 283-286 
running, 287-288 
Version 2 
CreateldentityPalette() 
function, 297-298 
DeleteWinGStuff() 
function, 296-297 
OnDraw() function, 298 
programming, 288-294 
running, 294 
SetUpWinGStuff() 
function, 295-296 


Aztec Adventure 


Version 3 
CAztecDoc class 
constructor, 304-305 
CopyDIBToWinG() 
function, 305-306 
CreateIdentityPalette() 
function, 305 
OnDraw() function, 306 
programming, 298-303 
running, 303 
Version 4 
CalcNorthView(), 
328-329 
CalcView() function, 
326-328 
DrawView() function, 
329-330 
LoadLevel() function, 
324-325 
OnUpdate() function, 
325-326 
programming, 313-330 
running, 323 
Version 5 
DoMove() function, 
338-347 
MoveForward() function, 
337-338 
OnKeyDown() function, 
336-337 
programming, 331-339 
running, 335 
ShowScene() 
function, 330 
TurnLeft() function, 337 
Version 6 
DisplayCompass() 
function, 351 
DoForwardButton() 
function, 350-351 
HandleForwardButton() 
function, 349 
OnLButtonDown() 
function, 348-349 
OnLButtonUp() 
function, 350 
programming, 339-347 
running, 347 
Version 7 
programming, 353-357 
running, 357-358 
ShowDoor() function, 
359-367 
ShowTreasure() function, 
358-359 


Version 8 
Get Treasure() function, 
367-368 
GetPotion() function, 
368-369 
programming, 362-367 
running, 367 
ShowMessage() 
function, 368 
Version 9 
DisplayKeys() function, 
374-375 
programming, 369-373 
running, 373 
Version 10 
programming, 376-378 
running, 378 
Version 11 
CheckLevel() function, 
388-389 
DisplayStats() function, 
386-388 5 
programming, 381-386 
running, 386 
UpdateExperience() 
function, 388 
Version 12 
DeleteFloorDIBs() 
function, 400-401 
GetMonsterDIB() 
function, 402 
LoadFloorDIBs() 
function, 399-400 
programming, 392-397 
running, 397 
ShowMonster() function, 
401-402 
Version 13 
DoNextMonsterFrame() 
function, 410-412 
FightMonster() 
function, 409 
killMonster() function, 
412-413 
OnTimer() function, 
409-410 
programming, 402-408 
running, 408 
Version 14 
HandlePotions() 
function, 421-422 
PlayerWins() 
function, 422 
programming, 413-419 
running, 419-420 
ShowScore() function, 
422-423 
StartNextFloor() function, 
423-425 


Version 15 
programming, 432-434 
running, 434 
sndPlaySound() function, 
434-436 
weapons/armor, 167 


BitBlt() function, 15 
BITMAPFILEHEADER 
structure (DIBs), 16-17 
BITMAPINFO structure 
(DIBs), 17 
BITMAPINFOHEADER 
structure (DIBs), 17-19 
bitmaps 
bottom-up bitmaps, 
102-103, 116 
copying to source 
bitmaps, 126-128 
data, indexing, 121-123 
device-dependent bitmaps, 
15-16 
device-independent bitmaps, 
15-16 
formulas, generalizing, 
124-125 
selecting into WinG DC, 105 
size differences, 123-124 
source bitmaps 
blitting, 125-126 
copying between, 
120-121 
translating, 129-131 
top-down bitmaps, 102-103, 
115-117, 129-131 
WinG, 81-82 
WinG bitmaps, 81-82, 105 
blitting source bitmaps, 
125-128 
bottom-up bitmaps, 116 
copying to source bitmaps, 
126-128 
WinG, 102-103 
Build command (Project 
menu), 45 
building dungeon floors 
(Aztec Adventure), 170-171 


C 


CalcNorthView() function, 
328-329 
CalcView() function, 326-328 
CAztecDoc (StartNextFloor() 
function), 424-425 
CAztecDoc class constructor, 
304-305 
CAztecView (Aztec Adventure) 
StartNextFloor() function, 
423-424 
CDib class, 20-31, 26-30 
programming, 22-26 
public member functions, 22 
CheckLevel() function, 
388-389 
ClItem structure (Dungeon 
Designer), 209-210 
ClassWizard command 
(Project menu), 41 
codes, inserting (SHOWDIB), 
40-45, 53-55, 61-62 
color tables (WinG), 118-119 
colors 
graphics objects, 454 
identity palettes, 118-119 
see also dithered colors, 
palette colors 
combining shading/offset 
stamping (3-D graphics), 
448-449 
commands 
File menu 
Exit, 95 
New, 32 
Open, 39, 176 
Print, 174 
Print Preview, 174 
Print Setup, 174 
Save, 176 
Save As, 176 
Help menu 
About Aztec 
Adventure, 288 
About Dungeon 
Designer, 192 
About Showdib, 39 
About Wingex, 95 
Project menu 
Build, 45 
ClassWizard, 41 
Edit, 521 
Execute, 35 
Execution, 95 


Files, 42, 96 
Open, 521 
Rebuild All, 35, 95 
Start menu (Run), 83 
View menu (Toolbar), 192 
controls, 10-11 
CopyDIBToWinG() function, 
120-123, 305-306 
CopyDIBToWinGTrns() 
function, 141-142, 145 
copying 
colors (identity palettes), 
118-119 
source bitmaps, 131-134 
to bottom-up bitmaps, 
126-128 
CPtrArray (Dungeon 
Designer), 210-211 
CreateBitmap() function, 15 
CreateDibPalette() function, 
55-57 
CreateldentityPalette() 
function, 117, 297-298, 305 
CreateWinGDibPalette() 
function, 107-108 
CWingexView class 
constructor, 101-102 
WinG bitmaps, 104-105 
WinG DC (device context), 
creating, 104 
WinG palette, creating, 
104-105 
CWingexView class 
destructor, 108-109 


D 


data files (Aztec Adventure), 
176-182 
DeleteContents() function, 
211-212 
DeleteFloorDIBs() function, 
400-401 
DeleteWinGStuff() function, 
296-297 
deleting sounds (Aztec 
Adventure), 429 
device-dependent bitmaps vs. 
device-independent bitmaps, 
15-16 
device-independent bitmaps, 
see DIBs 
dialog boxes 
About, 39, 95 
Add Class, 222 
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Add Member Function, 43 
Add Member Variable, 223 
File Open, 39 
Item, 171 
MFC ClassWizard, 41 
New, 32 
New Project, 32 
New Project Information, 34, 
92, 186 
Open, 46, 191 
Print, 192, 243 
Print Setup, 192 
Project Files, 42, 96 
Run Application, 83 
Scale, 430 
Step 1, 32 
Step 4 of 6, 33 
Step 6 of 6, 34 
WinG Setup Options, 83 
DIBs (dependent-independent 
bitmaps) 
CDib class, 20-31 
displaying, 32-49, 50-60 
loading, 26-30 
logical palettes, 50-53 
programming, 15 
SHOWDIB, programming, 
32-49 
structure types, 16-19 
system palettes, 50-53 
DisplayCompass() 
function, 351 
displaying 
DIBs (device-independent 
bitmaps), 32-60 
dungeon monsters (Aztec 
Adventure), 392-402 
dungeon objects (Aztec 
Adventure), 353-362 
DisplayKeys() function, 
374-375 
DisplayStats() function, 
386-388 
dithered colors (graphics 
objects), 454 
DoForwardButton() function, 
350-351 
Doggie (WinG programs), 
86-89 
DoMove() function, 338-347 
DoNextMonsterFrame() 
function, 410-412 
doors (Aztec Adventure), 173 
displaying, 353 
drawing graphics objects 
drop shadows, 453 
glass, 451-452 


540 drawing graphics objects 


luminous objects, 452-453 
metal, 450-451 
DrawSquare() function, 
230-231 
DrawView() function, 329-330 
drop shadows, drawing 
(graphics objects), 453 
Dungeon Designer (Aztec 
Adventure), 169, 183 
data/graphics files, 176-182 
dungeon floors 
building, 170-171 
loading, 175-176 
printing, 174 
saving, 175-176 
file listings, 248-282 
item numbers/values, 
171-173 
viewing, 173-174 
keys/doors, 173 
programming, 185-240 
Version 1 
programming, 185-191 
running, 191-192 
Version 2 
programming, 194-196 
running, 196-197 
Version 3 
OnCreate() function, 
202-204 
OnDraw() function, 
204-209 
programming, 197-201 
running, 201 
Version 4 
ClItem structure, 209-210 
CPtrArray, 210-211 
DeleteContents() 
function, 211-212 
OnNewDocument() 
function, 212-213 
programming, 204-209 
running, 209 
Serialize() function, 
213-215 
Version 5 
DrawSquare() function, 
230-231 
FindItem() function, 
238-248 
HandleLeftClick() 
function, 229-230 
OnLButtonDown() 
function, 228-229 
OnUpdate() function, 
226-228 


PlaceItem() function, 
231-234 
PlaceWall() function, 231 
programming, 215-224 
running, 225 
Version 6 
OnPreparePrinting() 
function, 243-244 
OnPrint() function, 
244-245 
OnRButtonDown() 
function, 241-243 
PrintMap() function, 
246-248 
programming, 235-240 
running, 240-241 
dungeon floors (Aztec 
Adventure) 
building, 170-171 
exploring, 164-165 
keys, 166-167 
loading, 175-176 
printing, 174 
saving, 175-176 
switching, 168 
weapons/armor, 167 
dungeon grids (Aztec 
Adventure) 
3-D view, 307-312 
dungeon floors, building, 
170-171 
item numbers/values, 
171-173 
viewing, 173-174 
dungeon monsters (Aztec 
Adventure) 
programming 
Version 12, 392-402 
Version 13, 402-413 
Version 14, 413-425 
fighting, 166 
dungeon objects, inserting 
(Aztec Adventure), 353 
dungeons (Aztec Adventure) 
monsters, programming, 
391-426 
sound, 427 


Edit command (Project 
menu), 521 

editing sounds (Aztec 
Adventure), 429-430 

elixir bottles (Aztec 
Adventure), 167 


Execute command (Project 
menu), 35 

Execution command (Project 
menu), 95 

Exit command (File menu), 95 

exploring dungeons (Aztec 
Adventure), 164-165 


fighting dungeon monsters 
(Aztec Adventure), 166 
FightMonster() function, 409 
file listings 
Aztec Adventure, 457 
Dungeon Designer, 248-282 
SHOWDIB, 64-76 
Visual C++ 1.5x, 516-520 
WINGEX, 145-159, 521-536 
File menu commands 
Exit, 95 
New, 32 
Open, 39, 176 
Print, 174 
Print Preview, 174 
Print Setup, 174 
Save, 176 
Save As, 176 
File Open dialog box, 39 
Files command (Project 
menu), 42, 96 
FindItem() function, 234-235 
functions 
BitBlt(), 15 
CalcNorthView(), 328-329 
CalcView(), 326-328 
CheckLevel(), 388-389 
CopyDIBToWinG(), 120-123, 
305-306 
CopyDIBToWinGTrns(), 
141-142, 145 
CreateBitmap(), 15 
CreateDibPalette(), 55-57 
CreateldentityPalette(), 117, 
297-298, 305 
CreateWinGDibPalette(), 
107-108 
DeleteContents(), 211-212 
DeleteFloorDIBs(), 400-401 
DeleteWinGStuff(), 296-297 
DisplayCompass(), 351 
DisplayKeys(), 374-375 
DisplayStats(), 386-388 
DoForwardButton(), 350-351 


DoMove(), 338-347 
DoNextMonsterFrame(), 
410-412 
DrawSquare(), 230-231 
DrawView(), 329-330 
FightMonster(), 409 
FindItem(), 238-248 
function quick reference 
(WinG), 437 
Get Treasure(), 367-368 
GetMonsterDIB(), 402 
GetPotion(), 368-369 
GlobalAllocPtr(), 29 
HandleForwardButton(), 349 
HandleLeftClick(), 229-230 
HandlePotions(), 421-422 
KillMonster(), 412-413 
KillTimer(), 145 
LoadBitmap(), 15 
LoadBitmapFile(), 26 
LoadFloorDIBs(), 399-400 
LoadLevel(), 324-325 
MoveForward(), 337-338 
OnCreate(), 143, 202-204 
OnDestroy(), 145 
OnDraw(), 47-49, 57-58, 
105-106, 204, 226-228, 
298, 306 
OnFileOpen(), 45-47 
OnKeyDown(), 336-337 
OnLButtonDown(), 228-229, 
348-349 
OnLButtonUp(), 350 
OnNewDocument(), 212-213 
OnPaletteChanged(), 63 
OnPreparePrinting(), 
243-244 
OnPrint(), 244-245 
OnQueryNewPalette(), 63-64 
OnRButtonDown(), 241-243 
OnTimer(), 143-145, 
409-410 
OnUpdate(), 226-228, 
325-326 
OpenDoor(), 378-379 
PlaceItem(), 231-234 
PlaceWall(), 231 
PlayerWins(), 422 
PrintMap(), 246-248 
see also, member functions, 
public member function 
Serialize(), 213-215 
SetUpWinGStuff(), 295-296 
ShowDoor(), 359-367 
ShowMessage(), 368 
ShowMonster(), 401-402 
ShowScene(), 330 


ShowScore(), 422-423 
ShowTreasure() function, 
358-359 
sndPlaySound(), 434-436 
StartNextFloor(), 423-425 
StretchDIBits(), 15, 48 
TurnLeft(), 337 
UpdateExperience(), 388 
WinG, 89-90 
WinGBitBlt(), 101 
WinGCreateBitmap(), 105 
WinGCreateDC(), 104 
WinGRecommend 
DIBFormat(), 101 


G 


game design, 8-9 
game programming 
elements, 7 
algorithms, 12 
animation, 11-12 
artificial intelligence, 12-13 
controls/interfaces, 10-11 
game design, 8-9 
game testing, 13-14 
graphic design, 9 
image handling, 11 
sound generation, 9-10 
game testing, 13-14 
GDI bitmaps, see device- 
dependent bitmaps 
generalizing bitmap formulas, 
124-125 
Get Treasure() function, 
367-368 
GetDibImageSize() (member 
functions), 30 
GetDibNumColors() (member 
functions), 31 
GetMonsterDIB() 
function, 402 
GetPotion() function, 368-369 
glass, drawing (graphics 
objects), 451-452 
GlobalAllocPtr() function, 29 
graphic design, 9 
Graphical Device Interface 
(GDI) bitmaps, see device- 
dependent bitmaps 
graphics 
3-D graphics, 443 
WinG, programming, 91-92 
graphics files (Aztec 
Adventure), 176-182 
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graphics objects, 449 
drop shadows, drawing, 453 
glass, drawing, 451-452 
icons, creating, 450 
limited colors, 454 
luminous objects, drawing, 
452-453 
metal, drawing, 450-451 
selecting, 450 
smoothing (antialiasing), 
454-455 
graphics programming 
(WinG), 79-81 


HALFTONE (WinG 
programs), 87 
HandleForwardButton() 
function, 349 
HandleLeftClick() function, 
229-230 
HandlePotions() function, 
421-422 
Help menu commands 
About Aztec Adventure, 288 
About Dungeon 
Designer, 192 
About Showdib, 39 
About Wingex, 95 


icons, creating (graphics 
objects), 450 
identity palettes, 117-118 
image handling, 11 
indexing bitmap data, 
121-123 
inserting 
codes (SHOWDIB), 40-45, 
53-55, 61-62 
dungeon monsters (Aztec 
Adventure), 391 
dungeon objects (Aztec 
Adventure), 353 
shadows (3-D graphics), 
445-447 
sound effects (Aztec 
Adventure), 431-432 
installing 
sound effects (Aztec 
Adventure), 432-434 
WinG, 83-85 
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interfaces, 10-11 
CDib class, 20-22 
Item dialog box, 171 
item numbers/values (Aztec 
Adventure), 171-172 
keys/doors, 173 
viewing, 173-174 


K-L 


keys (Aztec Adventure), 
166-167, 173 

KillMonster() function, 
412-413 

KillTimer() function, 145 


LED (light-emitting 
diode), 452 
listings, see file listings 
LoadBitmap() function, 15 
LoadBitmapFile() function, 26 
LoadFloorDIBs() function, 
399-400 
loading 
DIBs (device-independent 
bitmaps), 26-49 
dungeon floors (Aztec 
Adventure), 175-176 
LoadLevel() function, 324-325 
logical palettes 
colors, copying, 118-119 
DIBs, 54-77 
mapping into system 
palettes, 50-53 
structure, 107 
luminous objects, drawing, 
452-453 


m_Dungeon array (Dungeon 
Designer), 210-211 
mapping logical palettes, 
50-53 
member functions 
GetDibImageSize(), 30-32 
GetDibNumColors(), 31 
GetDibRGBTablePtr(Q), 31 
see also, functions, public 
member functions 
memory (DIBs), 26-30 
metal, drawing (graphics 
objects), 450-451 


MFC ClassWizard dialog 
box, 41 

Monster tool (Aztec 
Adventure), 171-173 

monsters, see dungeon 
monsters 

MoveForward() function, 
337-338 

moving source bitmaps, 

125-126 


navigating dungeon floors 
(Aztec Adventure), 168 

New command (File 
menu), 32 

New dialog box, 32 

New Project dialog box, 32 

New Project Information 
dialog box, 34, 92, 186 

numerical statistics (Aztec 
Adventure), 163 


oO 


objects 
graphics objects, 449-455 
see also, dungeon objects 

offset stamping (3-D 
graphics), 447-449 

OnCreate() function, 143, 
202-204 

OnDestroy() function, 145 

OnDraw() function, 47-49, 
57-58, 105-106, 204, 226-228, 
298, 306 

OnFileOpen() function, 45-47 

OnKeyDown() function, 
336-337 

OnLButtonDown() function, 
228-229, 348-349 

OnLButtonUp() function, 350 

OnNewDocument() function, 
212-213 

OnPaletteChanged() 
function, 63 

OnPreparePrinting() function, 
243-244 

OnPrint( function, 244-245 

OnQueryNewPalette() 
function, 63-64 

OnRButtonDown() function, 
241-243 


OnTimer() function, 143-145, 
409-410 
OnUpdate() function, 
226-228, 325-326 
Open command 
File menu, 39, 176 
Project menu, 521 
Open dialog box, 46, 191 
OpenDoor() function, 378-379 


P-Q 


palette colors (Aztec 
Adventure), 182 
palette messages (SHOWDIB), 
60-64 
palettes 
identity palettes, 117 
logical palettes (DIBs), 50-53 
system palettes (DIBs), 50-53 
WinG palette, creating, 
104-105 
PlaceItem() function, 231-234 
PlaceWall() function, 231 
player statistics (Aztec 
Adventure), 381-385 
CheckLevel() function, 
388-389 
DisplayStats() function, 
386-388 
UpdateExperience() 
function, 388 
PlayerWins() function, 422 
playing Aztec Adventure, 
162-168 
pointers (Visual 
C++ 1.5x), 515 
Print command (File 
menu), 174 
Print dialog box, 192, 243 
Print Preview command (File 
menu), 174 
Print Setup command (File 
menu), 174 
Print Setup dialog box, 192 
printing dungeon floors 
(Aztec Adventure), 174 
PrintMap() function, 246-248 
programming 
Aztec Adventure 
Version 1, 283-286 
Version 2, 288-294 
Version 3, 298-303 
Version 4, 313-330 
Version 5, 331-339 


Version 6, 339-347 
Version 7, 353-357 
Version 8, 362-367 
Version 9, 369-373 
Version 10, 376-378 
Version 11, 381-386 
Version 12, 392-397 
Version 13, 402-408 
Version 14, 413-419 
Version 15, 432-434 
CDib class, 22-26 
DIBs (device-independent 
bitmaps), 15 
Dungeon Designer 
Version 1, 185-191 
Version 2, 194-196 
Version 3, 197-201 
Version 4, 204-209 
Version 5, 215-224 
Version 6, 235-240 
SHOWDIB 
Version 1, 32 
Version 2, 50-60 
Version 3, 60-64 
WinG, 91-92 
WINGEX 
Version 1, 92-94 
Version 2, 96-101 
Version 3, 109-114 
Version 4, 134-140 
programs 
creating (Visual 
C++ 1.5x), 515 
WinG programs 
DOGGIE, 86-89 
HALFTONE, 87 
TIMEWING, 87 
see also, sample programs 
Project Files dialog box, 42, 96 
Project menu commands 
Build, 45 
ClassWizard, 41 
Edit, 521 
Execute, 35 
Execution, 95 
Files, 42, 96 
Open, 521 
Rebuild All, 35, 95 
pseudo 3-D view, see 3-D view 
public member functions 
CDib class, 22 
see also, functions, member 
functions 


Rebuild All command (Project 
menu), 35, 95 
recording sounds (Aztec 
Adventure), 427-429 
RES directory (AppWizard), 35 
responding to palette 
messages (SHOWDIB), 60-61 
RGBQUAD structure (DIBs), 19 
role-playing game (RPG), 161 
player statistics, 381 
Run Application dialog 
box, 83 
Run command (Start 
menu), 83 
running 
Aztec Adventure 
Version 1, 287-288 
Version 2, 294 
Version 3, 303 
Version 4, 323 
Version 5, 335 
Version 6, 347 
Version 7, 357-358 
Version 8, 367 
Version 9, 373 
Version 10, 378 
Version 11, 386 
Version 12, 397 
Version 13, 408 
Version 14, 419-420 
Version 15, 434 
Dungeon Designer 
Version 1, 191-192 
Version 2, 196-197 
Version 3, 201 
Version 4, 209 
Version 5, 225 
Version 6, 240-241 
SHOWDIB 
Version 1, 49 
Version 2, 59-60 
WinG, 86 
WINGEX, 145 
Version 1, 95 
Version 2, 101 
Version 3, 114 
Version 4, 140-141 


ShowTreasure () function 543 


S 


sample programs (WinG) 
DOGGIE, 86-89 
HALFTONE, 87 
TIMEWING, 87 
Save As command (File 
menu), 176 
Save command (File 
menu), 176 
saving dungeon floors (Aztec 
Adventure), 175-176 
Scale dialog box, 430 
selecting 
bitmaps into WinG DC, 105 
graphics objects, 450 
Serialize() function, 213-215 
SetUpWinGStuff() function, 
295-296 
shading (3-D graphics), 
448-449 
shadows, inserting (3-D 
graphics), 445-447 
SHOWDIB 
file listings, 64-76 
OnPaletteChanged() 
function, 63 
OnQueryNewPalette() 
function, 63-64 
Version 1 
codes, inserting, 40-45 
OnDraw() function, 
47-49 
OnFileOpen() function, 
45-47 


programming, 32 
running, 49 
Version 2 
codes, inserting, 53-55 
CreateDibPalette() 
function, 55-57 
OnDraw() function, 
57-58 
programming, 50-60 
running, 59-60 
Version 3 
codes, inserting, 61-62 
programming, 60-64 
ShowDoor() function, 359-367 
ShowMessage() function, 368 
ShowMonster() function, 
401-402 
ShowScene() function, 330 
ShowScore() function, 
422-423 
ShowTreasure() function, 
358-359 


544 smoothing graphics 


smoothing graphics 
(antialiasing), 454-455 
sndPlaySound() function, 
434-436 
sound effects (Aztec 
Adventure) 
creating, 431-432 
programming, 432-436 
sndPlaySound() function, 
434-436 
sound generation, 9-10 
sounds (Aztec Adventure) 
editing, 429-430 
recording, 427-429 
source bitmaps 
blitting, 125-126 
copying, 131-134 
to bottom-up bitmaps, 
126-128 
copying between, 120-121 
translating, 129-131 
standard system colors 
(identity palettes), 117-118 
Start menu commands 
(Run), 83 
StartNextFloor() function, 
423-425 
statistics, see player statistics 
Step 1 dialog box, 32 
Step 4 of 6 dialog box, 33 
Step 6 of 6 dialog box, 34 
StretchDIBits() function, 
15, 48 
switching dungeon floors 
(Aztec Adventure), 168 
system palettes (DIBs), 50-53 


T 


TIMEWING (WinG 
programs), 87 
Toolbar command (View 
menu), 192 
top-down bitmaps, 115-117 
source bitmaps, translating, 
129-131 
WinG, 102-103 
transferring bitmaps (WinG), 
81-82 
translating source bitmaps, 
129-131 
transparent blits, 141 
treasure chests, displaying 
(Aztec Adventure), 353 
TurnLeft() function, 337 
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UpdateExperience() 
function, 388 


View menu commands 
(Toolbar), 192 
viewing item values/numbers, 
173-174 
Visual C++ 1.5x 
file listings, 516-520 
pointers, 515 
vs. Visual C++ 2.0, 521 
Visual C++ 2.0, 515 
volume amplification (Aztec 
Adventure), 429 


W-Z 


Wall tool (Aztec 
Adventure), 170 
walls, displaying (Aztec 
Adventure), 307-312 
WAV files (sound 
recording), 427 
WaveStudio program, 428 
weapons/armor (Aztec 
Adventure), 167 
Windows (WinG), 82-83, 86 
WinG, 79 
Aztec Adventure 
Version 1, 283-288 
Version 2, 288-298 
Version 3, 298-306 
bitmaps, 81-82 
copying between, 
120-121 
creating, 105 
bottom-up bitmaps, 102-103 
CopyDIBToWinG() function, 
305-306 
CreateldentityPalette() 
function, 297-298, 305 
DeleteWinGStuff() function, 
296-297 
function quick reference, 
437-441 
functions, 89-90 
identity palettes, 117-119 
installing, 83-85 
OnDraw() function, 298, 306 
palettes, creating, 104-105 
programs (Doggie), 86-89 
running Windows, 86 


SetUpWinGStuff() function, 
295-296 
top-down bitmaps, 102-103 
Windows, 82-83 
WinG DC (device context), 
96-101 
bitmaps, selecting, 105 
creating, 104 
WinG Setup Options dialog 
box, 83 
WinGBitBIt() function, 101 
WinGCreateBitmap() 
function, 105 
WinGCreateDC() 
function, 104 
WINGEX 
file listings, 145-159, 
521-536 
OnCreate() function, 
141-142 
WinG DC (device context), 
96-101 
Version 1 
programming, 92-94 
running, 95 
Version 2 
CreateWinGDibPalette() 
function, 107-108 
CWingexView class 
constructor, 101-102 
CWingexView class 
deconstructor, 108-109 
OnDraw() function, 
105-106 
programming, 96-101 
running, 101 
Version 3 
CopyDIBToWinG() 
function, 123 
CopyDIBToWinG() 
function, 120-123 
CreateldentityPalette() 
function, 117 
programming, 109-114 
running, 114 
Version 4 
OnCreate() function, 143 
OnDestroy() 
function, 145 
OnTimer() function, 
143-145 
programming, 134-140 
running, 140-141 
WinGRecommendDIBFormat() 
function, 101 
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